My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

SSL: Another reason not to ignore IPv6

Published: 2013-05-17. Last Updated: 2013-05-17 17:09:08 UTC
by Johannes Ullrich (Version: 1)
3 comment(s)

Currently, many public web sites that allow access via IPv6 do so via proxies. This is seen as the "quick fix", as it requires minimum changes to the site itself. As far as the web application is concerned, all incoming traffic is IPv4. 

The most obvious issue here is logging, in that the application only "sees" the proxies IP address, unless it inspects headers added by the proxy, which will no point to (unreadable?) IPv6 addresses.

But there is another issue: SSL Certificates. If only IPv6 connections are passed via the proxy, you will end up with two different certificate: One for the proxy, and one for the web application (or the IPv4 proxy). It may also happen that the IPv6 and IPv4 site are considered two different hosts on the web server, requiring distinct configurations.

For example, at this point, "www.socialsecurity.gov" uses two different certificates. One for IPv6 and one for IPv4. The IPv6 certifiate is expired, while the IPv4 certificate is valid. This is in particularly painful as some simple comand line tools, like "openssl s_client' are still not able to work over IPv6. For my test, I used gnutls-cli, which works similar to openssl s_client but supports IPv6.

Excerpt from the result:

 

gnutls-cli -p 443 --x509cafile /opt/local/share/ncat/ca-bundle.crt www.socialsecurity.gov
Processed 291 CA certificate(s).
Resolving 'www.socialsecurity.gov'...
Connecting to '2001:1930:c01::aaaa:443'...
[...]
- subject `C=US,ST=maryland,L=baltimore,O=social security administration,OU=diias,OU=Terms of use at www.verisign.com/rpa (c)05,CN=www.socialsecurity.gov', issuer `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=Terms of use at https://www.verisign.com/rpa (c)10,CN=VeriSign Class 3 Secure Server CA - G3', RSA key 1024 bits, signed using RSA-SHA1, activated `2012-04-05 00:00:00 UTC', expires `2013-04-29 23:59:59 UTC', SHA-1 fingerprint `3286afd908f256947b396dbae88d37b111c9aaaf'
[...]
- Status: The certificate is NOT trusted. The certificate chain uses expired certificate. 
*** Verifying server certificate failed...
*** Fatal error: Error in the certificate.
*** Handshake has failed
GnuTLS error: Error in the certificate.
	 

Next, lets try IPv4. A disadvantage of gnutls-cli is that you are not able to force an IPv4 connection, so I will just fall back to openssl here:

$ openssl s_client -connect www.socialsecurity.gov:443 -CAfile /opt/local/share/ncat/ca-bundle.crt
[....]
subject=/C=US/ST=maryland/L=baltimore/O=social security administration/OU=diias/OU=Terms of use at www.verisign.com/rpa (c)05/CN=www.socialsecurity.gov
issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
[...]
 
And after saving the certificate to a file:
 
$ openssl x509 -in /tmp/ssa.gov -text
[...]
Validity
        Not Before: Apr 22 00:00:00 2013 GMT
        Not After : Apr 30 23:59:59 2017 GMT
        Subject: C=US, ST=maryland, L=baltimore, O=social security administration, OU=diias, OU=Terms of use at www.verisign.com/rpa (c)05, CN=www.socialsecurity.gov
So in short: two different certificates for the same host name. This isn't always bad, and not uncommon. But all certificates have to be valid!

------ Johannes B. Ullrich, Ph.D. SANS Technology Institute Twitter

3 comment(s)
My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

Comments

My American tax dollars...hard at work...NOT.
Well for most proxies you configure to forward the IPv4 to the web proxied web host. Certs is more tricky, but not too bad.

Really, this seems like all the more reason to NOT support using IPv6 if you don't have support already in your applications or infrastructure. Go all the way or don't bother.
I can't count on my hands, the number of times in the past that i've been ordered to just to turn off SSL on a project, if there is a certificate warning, even if the app is for something such as logging, reporting, or infrastructure monitoring, that could inherently be a bit sensitive, and to login to the application users' logins/passwords (maybe the same as their AD credentials) will be sent over HTTP via HTML form, or a cleartext LDAP bind (because hey, single signon is supported and required, but a SSL cert is too much trouble).

The client/IT manager will say "It's behind the firewall, and therefore only accessible from inside our corporate internal network, so just turn SSL off; not worth paying for a certificate anyways"

The same lets new network equipment that only supports Telnet or plain HTTP for management get deployed, and avoids the cost of replacing with SSH-enabled stuff or paying extra license fees for crypto.


[Invariably, the demand will come in later, to make the application publicly accessible, because VPN'ing in is too much trouble -- still with no SSL though, but hey, a password is required, so its secure]



So maybe it's more about reasons not to ignore SSL, than reasons not to ignore IPv6 :)

Diary Archives