Mozilla Public Suffix List
by Viktor Hansson on 04 April 2016, 06:38
So last week I got a message from a collegue, saying that a production environment for a service provider was down. A temporary fix was for us to change our config and point to a backup site of the service provider. So we tried calling the backup site to make sure it was up, and everything looked fine. So we changed the config, but when our code made calls to the SP, we saw the following message in our logs:
After going home and eating dinner I did some more googling and discussed the issue with another collegue, and finally I found this issue with the apache httpclient, that stated that something called Mozilla Public Suffix List. This is a list of domain suffixes for which wildcard certificates should be considered invalid, like *.com ,*.se or *.tumblr.com, since otherwise theses certs could be used on literally all .com domains without as much as a warning. So checking the libs showed that we used httpclient 4.4, which checks this list when validating wildcard certificates. And after a search in the list, lo and behold *azurewebsites.net.
To verify that this was in fact the issue, my collegue compiled some code with first httpclient 4.4, which showed the error, and then with httpclient 4.3, which connected with no issue.
So in my mind the question is not how can we disable the MPSL, but instead how was someone able to obtain a valid certificate with a wildcard domain for a domain on the list...
javax.net.ssl.SSLPeerUnverifiedException: Host name 'foobar.azurewebsites.net' does not match the certificate subject provided by the peer (CN=*.azurewebsites.net)Since everyone at our company knows that I'm the "security guy", this was naturally bounced to me. My first instict was to check if the TLS implementation our code used even had support for wildcard domains in certificates. After some googling and answers of variyng quality I landed on the JSSE (Java Secure Socket Extension) documentation page and saw that wildcards were in fact supported. So then I figured it could be something strange with the SANs (Subject Alternate Name) on the certificate, but quickly proved this wrong be running:
openssl s_client -connect foobar.azurewebsites.net:443Then copying the certificate to a file and inspecting it with:
openssl x509 -text -noout -in cert.crtBut this showed that all seemed right with the cert at least. I got a message that the main production environment was up again so this was no longer an urgent matter, but it still eluded me as why the above message would be printed.
After going home and eating dinner I did some more googling and discussed the issue with another collegue, and finally I found this issue with the apache httpclient, that stated that something called Mozilla Public Suffix List. This is a list of domain suffixes for which wildcard certificates should be considered invalid, like *.com ,*.se or *.tumblr.com, since otherwise theses certs could be used on literally all .com domains without as much as a warning. So checking the libs showed that we used httpclient 4.4, which checks this list when validating wildcard certificates. And after a search in the list, lo and behold *azurewebsites.net.
To verify that this was in fact the issue, my collegue compiled some code with first httpclient 4.4, which showed the error, and then with httpclient 4.3, which connected with no issue.
So in my mind the question is not how can we disable the MPSL, but instead how was someone able to obtain a valid certificate with a wildcard domain for a domain on the list...
Using a VPN for my home network
by Viktor Hansson on 06 August 2015, 07:24
I recently switched my home router from an Airport extreme to an Asus RT66U. The first thing I did was to replace the stock firmware with the Merlin firmware, which is very similar to the stock one, except that it has much more features. One of these features is an integrated OpenVPN server and client. I've wanted to have my home network through a VPN for a long time so I though that I should take advantage of this.
I did some research into which VPN provider I should use and landed on AirVPN. They have a 3-day trial for 1€ which I'm currently on. What I escpecially like about this provider is that they seem to have a good enough privacy policy, as well as having many servers in different countries. Its also really simple to switch between different servers. I'm currently using one in Sweden, since this means the traffic isn't leaving the country and is not in the hands of FRA.
Now if I just had a normal home network and wanted all my traffic tunneled that would be it. But of course that is not good enough for me. The problems that arise are that:
- I have multiple services within my network that needs to be exposed.
- I have a pretty fast connection (250/100) which I want to use for torrent downloads and gaming, so I only want web traffic to go through the tunnel.
This posed a problem with routing, since the only option in the vpn client on the router was to redirect all internet traffic or none (however this option didn't seem to change anything). What happended when the VPN was connected was that the tunnel was added as the default gateway
admin@RT-AC66U-AE28:/tmp/home/root# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 52.102.145.143 81.170.225.1 255.255.255.255 UGH 0 0 0 eth0 81.170.225.1 0.0.0.0 255.255.255.255 UH 0 0 0 eth0 10.0.1.0 0.0.0.0 255.255.255.0 U 0 0 0 br0 81.170.225.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 10.4.0.0 0.0.0.0 255.255.0.0 U 0 0 0 tun11 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 10.4.0.1 128.0.0.0 UG 0 0 0 tun11 128.0.0.0 10.4.0.1 128.0.0.0 UG 0 0 0 tun11 0.0.0.0 81.170.225.1 0.0.0.0 UG 0 0 0 eth0
This is the routing table with the vpn connected (IPs changed). To explain breifly the default gateway is used to determine where a packet should go if there are no other routes it matches. For example if someone sends me a packet with source x.x.x.x. When I respond the destination on that packet is x.x.x.x. The packet goes to my router, and it knows that the packet can not be directly sent to that computer since its not in the same network. It then sends it to the default gateway and hopes that that router/computer knows where to send it.
This also means that when gaming the packets will be sent through the VPN, and since the response time and bandwidth of the VPN is much lower than what I have directly, there could/would be lag. So I followed this guide and added the following rules on the router.
ip route add default table 100 via 81.170.225.1 ip rule add fwmark 1 table 100 ip route flush cache iptables -t mangle -I PREROUTING -i eth1 -p tcp -m multiport ! --dport 80,443 -j MARK --set-mark 1
This creates a new routing table named 100 with 1 rule: use the ISP gateway for everything.
The second command adds a rule to use the 100 table to route all packets that are marked with 0x1.
Next command flushes the routing cache.
admin@RT-AC66U-AE28:/jffs/scripts# ip rule 0: from all lookup local 32765: from all fwmark 0x1 lookup 100 32766: from all lookup main 32767: from all lookup default admin@RT-AC66U-AE28:/jffs/scripts# ip route show table 100 default via 81.170.225.1 dev eth0
Finally add a rule to the PREROUTING chain (packets pass this before going through the routing tables) which marks all tcp packets on the interface eth1 that has a destination port other than 80 or 443. This will mean that http(s) request will not be marked and be routed the main routing table (which uses the VPN). All other packets will be using the ISP gateway to get to the destination. I then had to add this rule for all interfaces except eth0 which is the wan interface
This works well, it does exactely what its supposed to do. However there is a problem. When someone does a http request against my ip the packets goes in to my load balancer and are processed. When time comes for the LB to return them, it sends the packet back through the VPN which of course has no knowledge of this connection and drops it. Therefore the following rule is required:
iptables -t mangle -I PREROUTING -p tcp -s ${LB_IP} ! -d ${LAN_NET} -m multiport --sport 80,443 -j MARK --set-mark 1 This makes sure that packets that originates from the LB and has the source port 80 or 443 are also marked with 1, therefore using the 100 table to route through the ISP.
Although as I'm typing this I realize that since the destination port on those packets is not 80 nor 443 it should be marked by the first rule... There was some problem though that since table 100 routes everything on dev eth0 I could not access my servers from within my own network, since that should be routed on the routers lo interface...
In any case this setup works, so I will not fiddle with it anymore. I finally added a similar rule as the one above with smtp and imap ports for the mail server to work, and rules to mark all udp and icmp traffic (since most games use udp, and I want to have reliable pings).
iptables -t mangle -I PREROUTING -p tcp -s ${MAIL_HOST} ! -d ${LAN_NET} -m multiport --sport 25,465,587,993,143 -j MARK --set-mark 1
iptables -t mangle -I PREROUTING -i eth1 -p udp -j MARK --set-mark 1For my particular router the interfaces I added these rules for where vlan1, vlan2, eth1, eth2. And to make it permanent I enabled user scripts and placed this script in /jffs/scripts/openvpn-event. Make sure its executable:
chmod +x /jffs/scripts/openvpn-eventThats all, I now have my webtraffic through a VPN. There is one more problem that I have yet to resolve. DNS. Currently I have manually set the routers dns servers to OpenDNS servers, however I have selected the option to use dns servers pushed by the VPN, but I'm not really sure if this is successful. I will have to continue investigation.