• NOTA BENE - WORK IN PROGRESS - Your Inputs & Thoughts

• To Technology Laboratory - To Technology Laboratory - Overview Projects - To comma Workbench SNI/TLS

---

SNI/TLS - Technology Background

• SNI/TLS is short for Server Name Indication / Transport Layer Security

• more about Description SNI - source: en.wikipedia.org

• more about Description TLS - source: en.wikipedia.org

Significant Technical Standards

• The Internet Engineering Task Force -IETF for Request for Comments - RFC

  • RFC 5430 - Suite B for TLS Text only - Website Version Text only - Print Version .pdf Download

  • RFC 5289 - TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM) Text only - Website Version Text only - Print Version .pdf Download

  • RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2 Text only - Website Version Text only - Print Version .pdf Download

  • RFC 4492 - Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Text only - Website Version Text only - Print Version .pdf Download

  • RFC 4346 - The Transport Layer Security (TLS) Protocol Version 1.1 Text only - Website Version Text only - Print Version .pdf Download

  • RFC 2246 - The TLS Protocol Version 1.0 Text only - Website Version Text only - Print Version .pdf Download

  • RFC 2119 - Key words for use in RFCs to Indicate Requirement Levels Text only - Website Version Text only - Print Version .pdf Download

Inclusion Status / Compatbility

More detailed compilation also on libraries can be found on Wikipedia (but without Distro Information.

• http://en.wikipedia.org/wiki/Server_Name_Indication

Client Side

• Mozilla Firefox (and other Gecko-based): Since 2.0
• Internet Explorer: since Windows 6.0 (Vista / 2008), not under Windws XP

• Safari (Mac OS 10.5.6, Windows >= Vista)

• Opera: Since 8.0

• Google Chrom (Windows >= Vista)

Servers

• Apache 2.2.12: Integrated - see table with your OS/distro if it's enabled/available or not.
• Cherokee if compiled with TLS support
• lighthttpd Version 1.4.x and 1.5.x with patch, or 1.4.24+ without patch
• Nginx with an accompanying OpenSSL built with SNI support
• acWEB with OpenSSL 0.9.8j and later (on Windows)

Technical Tests

• Text

---

Edit conflict - other version:

---

• Suite B for TLS

Technical Tests

• Text

---

Edit conflict - your version:

---

---

End of edit conflict

---

---

---

Edit conflict - other version:

---

---

Edit conflict - your version:

---

---

End of edit conflict

---

Inputs & Thoughts

• YYYYMMDD-YourName

• Text / Your Statements, thoughts and e-mail snippets, Please

---

Inputs & Thoughts

• YYYYMMDD-YourName

• Text / Your Statements, thoughts and e-mail snippets, Please

---

• 20091005- KyleHfrom E-Mail

• The short version: Short names are only necessary in the certificate
  if the system is addressed by its netbios name(s).  There might be a
  small SNI capability to allow the server to choose which
  certificate/keypair it wants to use for that name, but in the absence
  of that TLS extension all of the names that the server can be
  addressed by *must* be in the only certificate it can present.  This
  is why the short names are considered to be necessary in those
  certificates.
  
  I believe from what I have read (but do not know for certain) that an
  Exchange server that is only referenced by its DNS/Active Directory
  names only needs to have the DNS names that it is referred to in the
  subjectAlternativeNames extension in its certificate.  However, I only
  did the analysis a couple of days ago, and I may have missed something
  which makes my conclusions incorrect.  (I use a Mac, and don't have
  Exchange or Outlook 2007 to test with.)
  
  -Kyle H

---

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

why

• 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:

  • There is only one mode, and it's secure.

• 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>

Microsoft 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!

• Note: Non-SNI enabled Microsoft Products - IIS and IE6/7 for WindowsXP

stats

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

  • Number of SSL sites: 600,000 from Netcraft
  • Cost of phishing to US: $2.1 billion dollars.
  • Number of expired certs: 18%
  • Number of users who blame a glitch in the browser for popups: 4%

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

---

• 20090902-FredTrotter/e-mail

• I assume this will allow for may https sites to be hosted on a single IP address.. is that correct?

• 20090902-Iang/e-mail

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

---

• YYYYMMDD-YourName

• Text / Your Statements, thoughts and e-mail snippets, Please

---