This blog post is reaction to Qualys SSL research (see reactions here) and Security Now! podcast 255 which briefly covered the story.
The Qualys research process was as follows (simplified):
1. retrieve DNS domain names
2. check protocols open on the IP addresses related to the domain
3. check certificate on port 443
The result is a very good service SSLDB available on this URL: https://www.ssllabs.com/ssldb/index.html
However, the inherent problem with this process is that IP addresses may be shared between websites and a SSL check for one domain may actually be testing other website certificate.
The research was harshly criticised for flawed approach.
So is there a way to improve this situation? I think so.
What we need is to fully utilise a DNS feature that has been there for so long: SRV records.
Let me explain. Imagine you are owner of a website and you want all your users to prefer HTTPs. There is no way to tell the browser that there is HTTPs available on the server. But if you add following ecord and the bwowser checks it, they "Bob is your uncle":
_https._tcp.www.website.com 86400 IN SRV 0 5 443 www.website.com
_http._tcp.www.website.com 86400 IN SRV 0 5 80 www.website.com
This says to browser that the website is available on both http and https, so browser can simply go and connect on https.
Obviously, this requires domain administrators to populate DNS (not big deal) and web browsers to check for the SRV records. There is already an extension for Firefox that can prefer HTTPs, but this requires manual regular expression editing.
And it also means that DNS hosting companies need to allow their customer edit SRV records. My DNS company 123-reg certainly does not support it at the moment.
What do you think? Could this work and would it be useful? Worth an RFP?
Those who are criticising the methodology are focusing on the wrong aspect of the study. The goal of that initial research phase was not to show how many incorrectly configured SSL servers there were, but to find those SSL servers that _were_ well configured. The result is that there's about 720,000 of certificates that match the domain names on which they reside. The second phase of the research will focus on assessing those certificates (and SSL servers) in depth.
ReplyDeleteYour point about SRV records is a good one. I'd love to be able to state that my web sites support only SSL, and that no non-SSL connections are made. However, we'll need to wait for DNSSEC to become widespread before we can do that.
Why do you think we need to wait for DNSSEC? It certainly helps to protect integrity of authenticity of the responses but does not stop SRV records to be used. What is needed is a) DNS hostmasters to populate their DNS zones, b) webrowsers start making use of it. I wonder if this warrants a new RFC.
ReplyDeleteI encourage you to check out the Strict Transport Security spec. This is an opt-in approach that allows a website to instruct compatible browsers that the site should only be viewed over HTTPS. The spec is pretty robust and has controls in place to ensure the initial "instruction" occurs over a valid HTTPS connection. As long as users can safely get to the site once over SSL then they can get the STS flag set and be sure their browser will not send any http requests to the site in the future.
ReplyDeleteHere is a post on ForceHTTPS which is the predecessor to STS:
http://blog.mozilla.com/security/2009/07/27/locking-up-the-valuables-opt-in-security-with-forcetls/
Status of STS in Firefox:
http://blog.sidstamm.com/2009/11/update-on-https-security.html
Chrome supports STS already and Firefox will be supporting this very soon (not sure about IE).
Michael: Thank you for your comment. I studies the documents and I thing SRV records could further increase security and complement ForceHTTPs. More details in my recent blog.
ReplyDelete