LWN.net Logo

LFNW: Seth Schoen stumps for SSL

May 4, 2011

This article was contributed by Joe 'Zonker' Brockmeier.

Seth Schoen began his Getting HTTPS Everywhere talk at Linuxfest Northwest (LFNW) with an optimistic take. All that's required to have HTTPS Everywhere is that a few million more sites deploy HTTPS, the ones that have deployed HTTPS fix their implementations, find a way to fix the problems with the Certificate Authorities (CAs), and it's done. Piece of cake.

[Seth Schoen]

Perhaps it's not that simple after all. Schoen, senior technologist for the Electronic Frontier Foundation (EFF), explained early in the talk that the EFF isn't pursuing HTTPS adoption everywhere for grins — Schoen talked about Wireshark and Firesheep, and the ease with which people could snoop on others' Web traffic. He used examples of sniffing conversations over VoIP and other traffic, and said that it's "just out of convenience and courtesy" that most of the traffic that goes over a network isn't sniffed and viewed by someone else. However, convenience and courtesy only go so far — there are always those who are willing to go the extra mile to violate others privacy for fun, profit, or other nefarious purposes.

Thus the need for encryption over all connections, and not just for e-commerce sites, online banking, etc. The EFF and Tor Project released a Firefox extension called HTTPS Everywhere last year to help make it easier for users to enforce the use of HTTPS where it's supported. Schoen says that HTTPS adoption is much better than a year ago, particularly with popular sites like Google and Facebook. Even the US Federal Trade Commission (FTC) has called on Web services to start using HTTPS. Many sites now offer HTTPS as an option, though few offer HTTPS as the default.

So far, Schoen says that they estimate 500,000 users of the extension — though that is merely a drop in the bucket when you consider the number of people using Firefox (which passed 100 million downloads a few weeks ago). The extension now supports more than 700 sites, which may sound paltry until one realizes what's involved. It is not as simple as simply adding "s" to the "http" in a request, but actually requires users to verify that the same content is available at the URL if it is requested as "https" instead.

In some cases, like Wikipedia, it is not. For instance, requesting "http://www.wikipedia.org" will call up (as one might expect) the front page of Wikipedia. Requesting "https://www.wikipedia.org" gives an error. Users who want secure access to Wikipedia want "secure.wikipedia.org" instead. Requesting the Mozilla homepage without the "www" gives an error for an untrusted certificate, though requesting the HTTPS version of "www.mozilla.org" works fine. In short — too many sites on the Internet do not allow the user to simply assume that HTTPS will work with all links.

So the EFF is looking for more users to help. Schoen called on users to install HTTPS Everywhere, send bug reports when it doesn't work properly or sites have changed, and to help write rules for it. Naturally, it would also help if everyone responsible for a Web site would actually turn on HTTPS.

Users of Chrome and Chromium will be able to take advantage of the HTTPS Everywhere extension soon. Schoen said that Chrome/Chromium was not originally targeted because Chrome lacked the APIs necessary for HTTPS Everywhere. There's also an effort afoot to provide an HTTPS Everywhere Web proxy. He also gave a shout-out to the DuckDuckGo search engine, which has an option for rewriting searches so that users will be sent to the secure version of the resulting sites if available.

HTTPS Now

It doesn't help much to have the HTTPS Everywhere extension if sites don't have a secure version to redirect to. To that end, the EFF is working with Access on a program called HTTPS Now.

This effort includes resources for correctly deploying HTTPS and the ability to search for sites and see how (or if) they've deployed HTTPS. It also has a reporting system for users to explain how sites use HTTPS. For instance, users can report the name of the site, whether it only uses HTTPS on some pages or all pages, whether it uses secure cookies, has a valid SSL certificate, the key size of the certificate, and more. The reporting page has a lot of help to guide users who might not understand what a technology is, or how to determine if it's used. For instance, the help page for HTTPS Strict Transport Security (HSTS) explains HSTS and guides users to Qualys SSL Labs which has a SSL Server Test page which will examine a site and provide much of the information they want. (LWN, by the way, gets an overall rating of B from the service.) [ Editor's note: it would seem that accepting weak ciphers is the main thing dragging down our grade, which is something we plan to look into and fix in the near future. ]

SSL Observatory

Part of turning HTTPS on everywhere requires having a certificate — preferably not self-signed if one expects much traffic from users who have no way of verifying the veracity of a self-signed certificate. Not that certificates from CAs are always reliable. Schoen also talked about the SSL Observatory, another effort from the EFF to investigate certificates.

[Seth Schoen]

This is no small feat. According to Schoen the effort is trying to examine all publicly visible SSL certificates on the Internet. This has required making TLS connections to every IPv4 address. The EFF has found that certificates are signed by about 650 organizations that are trusted directly or indirectly by Mozilla and/or Microsoft as CAs.

Schoen says that the CA system has been subject to "a lot of little scandals," that are worrisome. For example, signing unqualified domain names like "exchange" instead of "exchange.host.tld", which is what the CAs are supposed to do. Then there's the recent Comodo incident where a reseller of Comodo certificates was compromised and an intruder obtained certificates for a number of targets. Though the certificates were almost immediately revoked, it demonstrated a potential problem with the CA and reseller structure.

Schoen noted that the system as it stands is rather fragile — not surprising given that it was invented by Netscape as a Band-Aid to calm fears about online credit card transactions.

For now, the EFF has been gathering data and examining it on its own. Schoen says that eventually the HTTPS Everywhere plugin would allow users to submit data to the Observatory. He also noted a few other efforts along the same lines, like the Perspectives Firefox extension and Google's certificate catalog.

The combined HTTPS efforts from the EFF and its partner organizations are enormous undertakings. Having all sites on the Internet (or even most) providing secure connections, and helping to reform the current CA mess, could take quite a few years. Pushing the awareness of the need for secure connections outside the tech community that understands the issues at hand will take quite a bit of effort, not just at the user level, but also at the site level. For instance, while Google and Microsoft have HTTPS for their Webmail offerings, Yahoo only offers HTTPS at login — when one logs into Yahoo Mail using HTTPS, they're immediately shunted to HTTP after login.

This will not be an easy fix, but the EFF's efforts are already bearing fruit. While a half-million users is a drop in the bucket, it's an impressive uptake for one year's effort. The EFF (and tools like Firesheep) have helped drive awareness over the last year and encouraged some major sites to push their users to secure connections, which is a good start — but not enough. Users would do well to check out the resources offered by the EFF, to participate in the Observatory and other efforts as time allows, and push their own organizations to offer HTTPS everywhere as well.


(Log in to post comments)

LFNW: Seth Schoen stumps for SSL

Posted May 5, 2011 6:05 UTC (Thu) by butlerm (subscriber, #13312) [Link]

Realistically, why would any small non-commercial site want to pay for a SSL certificate that must be renewed at considerable real cost every few years? I wouldn't even _want_ a certificate unless it was a wildcard certificate that didn't need to be renewed for ten years.

Furthermore, why can't DNS registries do the certificate signing for the domains they serve? No one is in a better position to know that party X is the owner of domain Z. Surely the .com registry operator is a shade more trustworthy than three hundred some odd CAs with blanket power to sign anything they want as well.

The various country specific TLD admins could similarly be safe in the knowledge that no one outside of their knowledge and control could sign recognized certificates for next level domains under their TLD. Certificates could be revoked on the moment of domain transfer, and the registry operators could presumably include revocation records as part of the response to DNS name server queries for the corresponding domain.

LFNW: Seth Schoen stumps for SSL

Posted May 5, 2011 10:00 UTC (Thu) by osma (subscriber, #6912) [Link]

It's not just the hassle and cost of a CA signed certificate, these have recently become much cheaper and easier to acquire (in a good and bad sense). But in the current situation also having a dedicated IPv4 address for each HTTPS site is still needed.

I help run a small ISP and we host around 200 websites. Only a handful of these have HTTPS support. The rest are served on a couple of shared IP addresses. With the current shortage of IPv4 addresses it just doesn't seem realistic to allocate an IPv4 address to each site on the web. The site owners don't ask for HTTPS and the cost is too high. Luckily many of the sites we run are just read-only brochure sites with no personal information, so HTTPS is perhaps not that useful for them. But if the goal is "HTTPS everywhere" it's still a very long way off.

There are a couple of solutions forthcoming. IPv6 would of course solve the address scarcity problem, but it's not yet there. SNI would allow sharing a single IP address for multiple HTTPS sites, but the dominant OS is still Windows XP and Internet Explorer is the dominant browser, and this combination doesn't and apparently won't ever support SNI (in any version).

As I see it Microsoft is holding the world hostage by not implementing SNI. All the other major browsers have support for it even on Windows XP.

LFNW: Seth Schoen stumps for SSL

Posted May 6, 2011 8:42 UTC (Fri) by intgr (subscriber, #39733) [Link]

> It's not just the hassle and cost of a CA signed certificate, these have recently become much cheaper

The opposite is true. 2-3 years ago, GoDaddy sold 1-year domain-validated certificates for under $20 per year, now they're up to $50. Thawte used to sell them at $50, now that's $150. It's insane how they're ramping up prices for what's essentially microseconds worth of CPU time on their secure server.

The only exception that I know of, is StartSSL which gives you these certificates for free -- which is the fair price. People should support StartSSL instead!

LFNW: Seth Schoen stumps for SSL

Posted May 16, 2011 12:17 UTC (Mon) by robbe (guest, #16131) [Link]

[Certs are getting more expensive]
I am sure this goes into making their infrastructure more secure.</irony>

> It's insane how they're ramping up prices for what's essentially microseconds worth of CPU time on their secure server.

You would expect to buy foreign bank notes at the price it costs to produce them? Shares are usually no longer traded in paper form nowadays, but when they were, these share certificates(!) also cost more than paper+ink. So your jab seems a bit out of place.

I'd like to see a CA run like a public utility, with full transparency and accountability. Just a dream.

> The only exception that I know of, is StartSSL which gives you these certificates for free -- which is the fair price. People should support StartSSL instead!

I really would. But their free offer only seems to target individuals, not small businesses.

LFNW: Seth Schoen stumps for SSL

Posted May 16, 2011 12:50 UTC (Mon) by intgr (subscriber, #39733) [Link]

> You would expect to buy foreign bank notes at the price it costs to produce them?

Good point :) OTOH, with bank notes you're not usually buying snake oil.

> I really would. But their free offer only seems to target individuals, not small businesses.

You can do it as an individual, it makes no difference. Your sign-up information won't be included in the certificate anyway. Domain-validated certificates don't validate your identity, they only assure the user that they have a connection to the rightful owner/administrator of the domain name, without knowing who that owner is.

The business only comes in when requesting organization validated certificates.

LFNW: Seth Schoen stumps for SSL

Posted May 6, 2011 9:32 UTC (Fri) by wookey (subscriber, #5501) [Link]

The 'real IP needed' aspect of SSL is why I mostly don't do it, except where actualy necessary. Most of the sites I admin are just name virtual servers. Having to get real IPs for them would cost money. I guess it's another little thing to help IPv6 adoption, which is good. (not that any of my sites (or my home ISP) work with that anyway at the moment).

LFNW: Seth Schoen stumps for SSL

Posted May 6, 2011 13:33 UTC (Fri) by holstein (subscriber, #6122) [Link]

One could wonder which one will come first: usable IPv6 or usable SNI?

At my job, we sells white-labeled SaaS: while we can physically host hundreds of clients on an handfull of server, off one IP, offering HTTPS means getting one IP per client, a real pain. And it's not really an option to say we uses SNI and then drop support for a good percentage of our clients...

LFNW: Seth Schoen stumps for SSL

Posted May 5, 2011 11:30 UTC (Thu) by nbecker (subscriber, #35200) [Link]

SSL is a problem in some areas. Performance of SSL over satellite can be very poor, both because SSL requires many round trips, and because spoofing techniques used to accelerate long-delay paths can't work with encrypted data (that they can't decrypt).
For example, prefetching of web page content can't work on encrypted connections.

LFNW: Seth Schoen stumps for SSL

Posted May 16, 2011 11:57 UTC (Mon) by robbe (guest, #16131) [Link]

> Realistically, why would any small non-commercial site want to pay for a SSL certificate that must be renewed at considerable real cost every few years?

The same can be said about domains, the main difference being that they are cheaper. Why? Maybe because the security standards/expections are lower.

> Surely the .com registry operator is a shade more trustworthy than three hundred some odd CAs with blanket power to sign anything they want as well.

Probably true. But the registry doesn't interact with you directly. It trusts the registrars to do that. According to http://icann.org/en/registrars/accredited-list.html there are 968 accredited registrars, some with trust-inspiring names like "$$$ Private Label Internet Service Kiosk, Inc."

You are right, that the registry can probably act as a control against registrars going bezerk. It could no longer accept new clients via a "bad" registrar. This is harder for the browser vendors to accomplish without affecting old clients of the same registrar/CA.

That said, I'm all for the ability to store SSL public keys in DNSsec. We will see where the chips fall. Go DANEs!

LFNW: Seth Schoen stumps for SSL

Posted May 16, 2011 17:21 UTC (Mon) by job (guest, #670) [Link]

An interesting alternative for your long-time wildcard domains is CAcert, which has been close to viable a very long time now. I don't know what the current holdups in Mozilla and Chrome are, but any security reason would be almost too silly after the major CA screwups lately.

The common answer as to why domain registrars aren't best equipped to do this is that certificates does not (only) identity a domain, it identifies the owner. So when you do to LWN you know that you are at Eklektix Inc. and not some other LWN.

Personally I believe this is a complete misfeature as I am not interested in that, but that is the answer given. I applaud all attempts to store TLS keys in DNS but I understand how strong the economic incentives are not to rock the boat.

Apache SSL cipher suite

Posted May 5, 2011 11:24 UTC (Thu) by noah123 (subscriber, #58540) [Link]

If you terminate SSL in Apache, something like this will make Qualys' SSL tester happier.
# Use only high and medium security ciphers; block use of anonymous DH key exchanges
SSLCipherSuite HIGH:MEDIUM:!ADH
# Enable all SSL protocols but SSLv2, which is broken
SSLProtocol all -SSLv2
What's behind the cryptic HIGH:MEDIUM:!ADH string can be shown with openssl(1).
$ openssl ciphers 'HIGH:MEDIUM:!ADH'
DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:DHE-RSA-AES128-SHA:
DHE-DSS-AES128-SHA:AES128-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:
DES-CBC3-SHA:DES-CBC3-MD5:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:SEED-SHA:
RC4-SHA:RC4-MD5:RC2-CBC-MD5:RC4-MD5
HIGH and MEDIUM contains a number of default cipher suites with 128 bit key lengths according to the documentation. !ADH removes selected cipher suites which use anonymous Diffie-Hellman key exchanges. If you would want to remove all selected cipher suites that either make use of the SEED block cipher or use MD5 for hashing, you would append !SEED:!MD5 to the cipher suite string.
$ openssl ciphers 'HIGH:MEDIUM:!ADH:!MD5:!SEED'
DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:DHE-RSA-AES128-SHA:
DHE-DSS-AES128-SHA:AES128-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:
DES-CBC3-SHA:RC4-SHA

Apache SSL cipher suite

Posted May 6, 2011 20:40 UTC (Fri) by zooko (subscriber, #2589) [Link]

I don't really see the need to support 3DES or RC4 either, so I use:

ALL:+HIGH:!MEDIUM:!LOW:!EXPORT:!eNULL:!aNULL:+kEDH:+AES:+SHA1:!3DES:!DES:!RC4:!RC2:!IDEA:!SEED:!MD5:+kDHd:+kDHr:+aDSS:+DSS:+aRSA:+kRSA

Which shows the result:

DHE-DSS-AES256-SHA:DHE-DSS-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:AES256-SHA:AES128-SHA

Apache SSL cipher suite

Posted May 26, 2011 21:28 UTC (Thu) by silmaril (subscriber, #52105) [Link]

I got almost the same result by using "HIGH:!aNULL:!3DES" (which is somewhat simpler), just not sorted the same way (prio to 256bits ciphers):

DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1
DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1

If i add +kRSA and +aRSA then i got the same order, which i don't like:
DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1
DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1

But what about ads?

Posted May 5, 2011 13:22 UTC (Thu) by mrshiny (subscriber, #4266) [Link]

I'd love it if I could convince my managers to deploy SSL for all our sites. Currently we have a complicated mix of SSL and non-SSL. However, there are some major stumbling blocks.

1. Ads: Most ad networks don't offer SSL ads. I seriously doubt that we'll be dropping ads or implementing a completely custom ad solution.
2. Caching: Some of our content is cached externally by Akamai. How do we do this with SSL? Akamai has an SSL option, but it is extremely cumbersome. Lots of sites depend on third party caching, this generally doesn't happen with SSL.
3. Virtual hosting: As some one else mentioned, virtual hosting is a no-go with SSL. We rely heavily on it and certainly don't have enough IP addresses for each hostname to have its own IP.

None of these problems are insurmountable, but they will have to be dealt with before most sites can go SSL all the time.

What's the point of HTTPS Now?

Posted May 5, 2011 15:30 UTC (Thu) by intgr (subscriber, #39733) [Link]

I have a hard time seeing the point of this "HTTPS Now" web site. It tells users to figure and fill out and enter tedious information about the server's HTTPS configuration, and then displays it in an *alphabetized* list.

Surely the HTTPS Observatory project could collect all this data using more reliable automated methods. But I still couldn't see the point of presenting it in a huge list on a public web site.

LFNW: Seth Schoen stumps for SSL

Posted May 5, 2011 22:12 UTC (Thu) by Simetrical (guest, #53439) [Link]

FYI, Wikimedia Bug 20643 - Serve SSL/HTTPS sites out of same domain names as HTTP access: https://en.wikipedia.org/.

LFNW: Seth Schoen stumps for SSL

Posted May 8, 2011 16:51 UTC (Sun) by kleptog (subscriber, #1183) [Link]

And when we've solved the SSL problem for HTTP, what's next? SMTP? FTP?

One of the problems here is that SSL conflates two issues, namely encryption and authentication. And which problem is it that we're trying to solve? ISTM we want everything encrypted, so the solution would be to enable Anonymous Diffie-Hellman SSL without certificate. Then you encrypt everything with perfect forward secrecy and you have none of the issues with respect to needing more IPs.

I liked the idea of tcpcrypt (http://lwn.net/Articles/401943/), which offered transparent encryption of all TCP sessions. Note sure if it went anywhere...

LFNW: Seth Schoen stumps for SSL

Posted May 9, 2011 0:42 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]

if you don't do authentication, then how do you know if you are actually doing your encryption to the server you are trying to reach as opposed to doing the authentication to a bad guy sitting in the middle?

LFNW: Seth Schoen stumps for SSL

Posted May 9, 2011 0:57 UTC (Mon) by foom (subscriber, #14868) [Link]

You don't. But encryption without assurance of the endpoint is much better than not doing encryption at all. If you encrypt, the attacker needs to modify packets *in-flight*, rather than just intercepting them for later storage and search. Practically speaking, that's a lot harder, and also, you risk detection.

Right now, various entities are assuredly passively monitoring internet traffic, completely undetectably. Making that impossible, and forcing them to use active measures if they want to continue such monitoring seems like a good thing.

LFNW: Seth Schoen stumps for SSL

Posted May 16, 2011 17:28 UTC (Mon) by job (guest, #670) [Link]

I am not so sure. "In-flight" is slightly misleading as this would probably be done with DNS or BGP attacks. It could be done on a large scale, as we've already seen in Syria, Iran and Libya where Facebook logins are harvested this way.

Tools such as Firesheep are important to build a use case for transport security which is hard enough to explain without going into details on the difference between encryption and authentication and the necessity of both. Imagine credentials being stolen on an open wlan and exaplaining to that user why using encryption isn't enough.

Simply put, it may impose a false sense of security.

LFNW: Seth Schoen stumps for SSL

Posted May 13, 2011 9:37 UTC (Fri) by jengelh (subscriber, #33263) [Link]

>And when we've solved the SSL problem for HTTP, what's next? SMTP? FTP?

I do not see an issue with SMTP - it does support TLS. So you get the secure transport - if made available - on the same host and on the same port. SMTP/FTP cannot cause (apart from an error code and thus following the MX chain) the client to go to a different host like a HTML doc.

Google

Posted May 12, 2011 23:22 UTC (Thu) by Felix_the_Mac (guest, #32242) [Link]

What if Google preferentially returned https addresses for all sites that support it?

Copyright © 2011, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds