Information Campaign SNI/TLS

Description

Selected comma Weapons

comma Campaign Roll-Out

Inputs & Thoughts

Background - Details & Snippets

iang: collection of snippets and posts from the last 3-4 years on SNI for text material. Use & abuse at will...

why

1. So that virtual hosted sites -- the 99% -- can use TLS. This will lead grass-roots-style to an explosion in the use of TLS.

Why's that helpful? (a) it will raise the profile of TLS work enourmously, and that includes server-side and browser-side practices. It will help to re-direct all these resources above into security work in the browser. Right now, 1% of activity is in TLS. Priorities will change dramatically when that goes to 10%, and that means we can count on the browser teams to spend a whole lot more time on it. And (b) if all traffic goes over TLS, this reduces the amount of security work quite considerably because everything is within the TLS security model.

another explanation

The connection between all this dancing around with TLS and end-user security is a bit too hard to see in simple terms. It is all to do with SNI - server name indication. This is a feature only available in TLS. As explained above, to use TLS, SSLv2 must die.

Once we get SNI, each Apache server can *share* TLS certificates for multiple sites over one single IP number. Right now, sharing TLS sites is clumsy and only suitable for the diehards at CAcert (like this site is set up, the certs stuff causes problems). This makes TLS a high-priced option - only for "e-commerce" not for the net masses. Putting each site over a separate IP# is just a waste of good sysadmin time and other resources, and someone has to pay for that.

(Do you think the commerciality of the equation might explain the laggardness of browser manufacturers here?)

With SNI, using TLS then has a goodly chance of becoming virtual - like virtual HTTP sites sometimes called VHosts. Once we start moving more web servers into TLS _by default_, we start to protect more and more ... and we shift the ground of phishing defence over to certificates. Which can defend against phishing but only if used properly (c.f. toolbars).

Yes, I know, there are too many steps in that strategy to make for easy reading. I know, we already lost the battle of phishing, and it has moved into the Microsoft OS as the battleground. I know, TLS is bypassed as a security system. And, I know, SSL was really only for people who could pay for it anyway.

Still, it would be nice, wouldn't it? To have many more sites using crypto by default? Because they can? Imagine if websites were like Skype - always protected? Imagine how much easier it would be to write software - never needing to worry about whether you are on the right page or not.

More

This is the long-awaited fix in TLS that enables Apache webservers to do virtual hosting of the secured sites, something that has been missing since forever. Once we can do virtual hosting of secured sites, this means all the smaller operators using own Linux and BSD machines can move just about anything to TLS. This means people can finally start to employ security on websites as it was meant to be:

Unfortunately, the SSL model broke about five minutes after deployment when people separated the websites into non-SSL and SSL. Military people will quickly realise that this is a split-forces pattern, and a disaster that must and did happen. _Do not split your forces!_ is one thing that is hammered into the new recruit until the soldier mumbles it in sleep.

serverNameIndication or SNI is the most important fix there is in secure browsing today. I argue this in the face of strong candidates, such as security UI improvements, key continuity models (a.k.a. SSH), secure password protocols, EV, cardSpace, etc. The reason this is more important is that it is a structural & market forces change, not a technical change, and market forces trumps tech every time.

<obligatory><rant> Take EV for example, as the most popular answer to phishing. It adds around 1000 new certs to the market. The top end. And it changes little for those big companies, other than a new paint job. Green is in, this season, it seems. The industry is divided as to whether it adds nothing, or just a little. Even the EV people agree that it is not intended to solve phishing... Either way, most agree it isn't worth the bother (to resist or to implement), and it consumed significant resources which were therefore wasted.

In comparison, TLS/SNI will unleash one million Linux boxes that can now start serving 10 million websites in TLS. This is no paint job, SNI is a revolution in blood; most of those new certs will trigger IE's new warning colour as well. Currently, the Linux multitudes cannot serve security, more or less, because they have only one IP# each. It's just not worth the bother for one site, see the split-forces issue. With SNI, it removes a massive barrier: the IP# limitation, and we no longer have to compromise our security between the two models.

I predict we'll add a million new TLS websites over the few years after Apache SNI is released.

Which will then have a massive, truly massive knock-on effect on all developers of all software applications: Suddenly, developers will find their insecure applications being put into security areas, because TLS secures, right? Suddenly, ordinary developers will have to start thinking about security. Because if users mount secure websites, that means they need security, right? Suddenly, developers will discover an itch to get more familiar with security programming, practices and tricks. And this will all flow into their applications and across to users.

The humble cert will be reborn. Can this massive claim be true? The good part is that even if only a small part of it is true, it's a win for everyone except phishers... </rant></obligatory>

MS on phishing and TLS/SNI

... dropping SSL v2 as default: it's hard to concisely draw the complex connection between TLS and phishing, but it's easy to show its general or two-step effects. Microsoft makes a game attempt at this:

Lastly, the TLS implementation has been updated to support Extensions as described in RFC 3546. TLS extensions improve performance, and add capabilities to the TLS protocol. The most interesting of the extensions is the Server Name Indication (SNI) extension, as it resolves one of the long-standing limitations for HTTPS hosting.

A little background: When a web browser initiates a HTTPS handshake with a web server, the server immediately sends down a digital certificate. The hostname of the server is listed inside the digital certificate, and the browser compares it to the hostname it was attempting to reach. If these hostnames do not match, the browser raises an error.

The matching-hostnames requirement causes a problem if a single-IP is configured to host multiple sites (sometimes known as “virtual-hosting”). Ordinarily, a virtual-hosting server examines the HTTP Host request header to determine what HTTP content to return. However, in the HTTPS case, the server must provide a digital certificate before it receives the HTTP headers from the browser. SNI resolves this problem by listing the target server’s hostname in the SNI extension field of the initial client handshake with the secure server. A virtual-hosting server may examine the SNI extension to determine which digital certificate to send back to the client.

I told you it wasn't easy to explain ... in short, this means that many more ordinary sites can now use HTTPS to protect content, which speeds up the general availability of TLS (was SSL) which then kicks back and means browsers and plugins can protect against phishing. Top banana!

stats

https://financialcryptography.com/mt/archives/000961.html

Snippets from E-Mail

Dan said somewhere something quite important, at least for me. - have to find hugi

20090902 - If major webmail providers started providing built-in S/MIME capabilities (with keys stored on the server), or at the very least signature verification, that would be a huge step forward to wider adoption of S/MIME - pete

20090902 - While on the adoption route, let me blow another trumpet: TLS/SNI!

Recently, a big change started shipping in Apache's HTTPD webserver. This change is called TLS/SNI. It is IMO the most important change since v2. The reason for this is that TLS/SNI enables virtual hosting with certificates.

So, for the first time, we can now set up our Apache to use individual certificates for all vhosts.

This change is quite important. Before, people set up the Apache for vhosts and discovered that they needed exotic routing or exotic certificates in order to enable TLS. The normal result happened: people stopped using SSL, and left their website in the clear. SSL was unusable in the most popular, routine circumstance.

SSL was built with far too many crypto-techno-bureau-barriers for its own good. What some of us have been doing is eliminating those barriers. ONE of them is cert-price, hence CAcert. ANOTHER is the inability of SSL to be used in virtual contexts. So since around 2005, some of us (including CAcert people and Mozilla people) have been pushing the elimination of this bug.

The last-but-two step was done a month or two back: Apache HTTPD now ships with it. The last-but-one step is: does *your version of Linux, etc* ship with it?

The last step is for you out there: Have you installed and run and tested it?

Virtual, secure websites! Finally!

iang

PS: Pete, the reason I jump in here is because the number of barriers to S/MIME adoption remains relatively high. TLS/SNI gives us an easy win in the short term. - iang

On 02/09/2009 17:50, fred trotter wrote: I assume this will allow for may https sites to be hosted on a single IP address.. is that correct?

Yes, exactly! Browsers have had it for years. We are just waiting on servers.

iang