Three years ago, when I started this notebook, almost no website used HTTPS for anything except the credit-card transaction itself. Browsing was cleartext. The HTTPS adoption was minimal.
That has shifted, slowly but visibly. By my rough sampling — and several conversations I have had at last week's conference — HTTPS is now substantially deployed. Most online retail uses it for the entire purchase flow. Most banking sites use it for authentication and increasingly for the whole logged-in experience. Some general-purpose sites are starting to use it for sensitive logged-in pages.
This is a good shift. Worth writing about — what has changed, what is still missing, and what defenders should know about the current state.
What has changed
Three things, in increasing order of importance.
Browser support has matured. Netscape and Internet Explorer both support SSL 3.0 reliably; IE 5 has reasonable TLS 1.0 support; the lock-icon UI is familiar to most users. The friction of using HTTPS for users is essentially zero.
Server software has matured. Apache with mod_ssl is now stable and widely deployed. The configuration is documented, the performance is reasonable, the operational experience is well-understood. Microsoft IIS supports HTTPS in its standard configuration. The barrier to deploying HTTPS on a server has dropped substantially.
Certificate availability has improved. VeriSign is no longer the only practical option. Thawte is competitive on price and increasingly on quality; several other CAs have emerged. Annual certificate costs for a basic domain are now around £150-300 depending on the CA, down from over £500 a few years ago.
What has not changed
The CA model is still structurally weak. Browser trust is granted to a long list of CAs; compromise of any one of them produces certificates the browser will accept; the auditing of CAs is uneven; the revocation infrastructure (CRLs, OCSP) is not widely deployed.
This is a real but currently-mostly-theoretical concern. We are starting to see the early shapes of how it will eventually fail — the CAs that have had operational issues, the legitimate certificates that have ended up in the wrong hands. It is not yet a regular operational concern.
SSL 2.0 is still supported in deployments. SSL 2.0 has known weaknesses; it should not be used. Many servers and clients still negotiate it as a fallback. The right configuration is to disable SSL 2.0 on the server and accept the small loss of compatibility with very old clients.
Certificate validation is uneven. Most browsers do basic validation (check the chain, check the expiry, check the hostname matches). Many do not check revocation. Some old browsers are content with non-validated chains. The user warnings on validation failure are also uneven — some browsers warn loudly, some inconsistently.
Self-signed certificates produce noisy warnings. As I wrote when I built my own CA, browsers warn aggressively on certificates not signed by a trusted CA. The user-experience for this is bad enough that most operators end up paying for a commercial certificate even for internal services.
What deployments still get wrong
A short list of common mistakes I have observed in audits.
Mixing HTTP and HTTPS on the same site. A site where the login page is HTTP but submits to HTTPS gets the credentials encrypted in transit, but the login page itself could have been modified by an attacker on the network. The user has no way to verify they are typing into the legitimate page. Better: the entire authenticated experience over HTTPS, with the unauthenticated public pages as the only HTTP-permitted area.
Cookie scope mistakes. A cookie set on the HTTPS portion of a site, without the Secure flag, will be sent over HTTP if the user navigates to the HTTP portion. Anyone observing the network can capture the cookie. The fix is to set the Secure flag on session cookies; most frameworks support this.
Mixed content on HTTPS pages. An HTTPS page that includes images, scripts, or stylesheets from HTTP sources. The browser shows a warning (sometimes); the security of the page is compromised because the HTTP resources can be modified. The fix is to ensure all included resources are also HTTPS or are local.
Weak cipher suites. Some servers default to permitting weak ciphers (40-bit and 56-bit DES, RC2 with weak keys) for compatibility with old browsers. The compatibility benefit is small; the security cost is real. Modern configurations should permit only AES (where supported), 3DES, and similar 128-bit-or-stronger ciphers.
Missing certificate-chain delivery. A server should send not just its own certificate but the chain up to a trusted root. Many configurations send only the leaf certificate, relying on the browser to fetch intermediate certificates. This works mostly but produces compatibility issues with some browsers.
What defenders should know about the current state
HTTPS is necessary for any user-facing service, not just for credit-card transactions. The login pages, the admin interfaces, the user-data displays — all of these benefit from HTTPS. The deployment cost is now low enough that the benefit is straightforward.
HTTPS does not solve all problems. It encrypts traffic between client and server. It does not validate that the server is authentic beyond the certificate chain (which has structural weaknesses). It does not protect against authentication mistakes on the server side. It does not protect against malicious code running on the client (browser exploits, trojans). The defensive scope of HTTPS is precisely the network channel between client and server; everything else is a separate concern.
Performance impact is modest. A typical Apache server can sustain hundreds of HTTPS connections per second on commodity hardware. The CPU overhead of SSL is a few percent on modern processors. For most deployments this is in the noise.
Operational complexity has decreased. Three years ago, configuring HTTPS was substantial work — generating CSRs, working with the CA, configuring the server, debugging. Today the procedure is well-documented and the tooling is reliable. Friction is now a poor reason for not deploying HTTPS.
What I expect over the next few years
Three predictions, in roughly increasing order of confidence.
HTTPS adoption continues to grow. By 2003 I expect most user-facing sites to be HTTPS by default, with HTTP as the exception. The momentum is established and the friction is decreasing.
The CA system will eventually be challenged. Some specific incident — a major CA compromise, a publicised certificate-misissuance, a regulatory crisis — will force a reckoning with the trust model. The reckoning will not produce a clean replacement; it will produce a series of incremental improvements and partial alternatives.
TLS will eventually replace SSL completely. The TLS protocol is incrementally more secure than SSL 3.0; the migration from SSL 3.0 to TLS 1.0/1.1 will continue. By 2003 SSL 3.0 should be considered legacy; by 2005 effectively retired.
What I am doing
For the small services I run for friends, I have completed the HTTPS migration over the past several months — every internet-facing service is now HTTPS, with the personal CA setup I wrote about earlier this year for the cases where commercial certificates are not justified.
For the friends and small organisations I help, I have been recommending HTTPS migration as a default rather than as an option. The recommendation is well-received; most are getting around to it on a multi-year timescale.
For my own writing: HTTPS is now mature enough that the focus should shift from "is HTTPS deployed?" to "is HTTPS deployed correctly?". The list of common mistakes above is the kind of thing I expect to be writing about more, as deployment becomes ubiquitous and the operational details become the differentiator.
More as the year develops. The next few months will, on the available news, be busy — Microsoft has acknowledged a major IIS vulnerability that will dominate October, and there are rumblings of a substantial Microsoft security incident that may break before year-end.