TIL: HTTP Upgrade

I’m thinking about creating devproxy in a different language. Tracking down some relevant specs, I found the CONNECT RFC.

This RFC includes not only the definition of CONNECT, but alternatively, the use of an Upgrade header to convert a regular HTTP connection to HTTPS, either with optional or mandatory encryption. It was like STARTTLS for HTTP, in a way.

CONNECT won out in the real world, of course, but I find this lost feature kind of fascinating.

Quick comparison:

• Upgrade is a hop-by-hop header. The browser/proxy and proxy/upstream connection MAY be using different levels of encryption.
• When using Upgrade, the proxy needs a valid TLS certificate to handle encrypting traffic with its clients.
• Also, this means the proxy can still view/cache/log the data that was encrypted on the wire.

CONNECT is basically the opposite: once the request is made and the proxy allows it, the proxy reverts to being just as dumb as any router on the Internet. All it can do is shuttle the bytes, so the same bytes that leave the origin end up at the client without any caching or interpretation. Since CONNECT is mainly used for HTTPS, those bytes are most often encrypted, as well.

Google may have tried the Upgrade header when first developing SPDY, but they didn’t like the extra round-trip nor the ability for intermediate devices on the network to interfere (intentionally or otherwise.) So it didn’t end up getting resurrected from the dustbin of history for that, either.

So maybe I didn’t learn about it today, but only rediscovered it.

OpenSSL cipher cargo culting

From the new version of my dovecot conf that dpkg installed in the trusty upgrade:

ssl_cipher_list = ALL:!LOW:!SSLv2:ALL:!aNULL:!ADH:!eNULL:!EXP:RC4+RSA:+HIGH:+MEDIUM

oh God my eyes, why so much bleeding!?

TLS Cipher Suites in 2013

Things I learned digging around the RFCs and testing with the ssllabs server test:

1. SSLv3/TLSv1 ciphers listed in the original specifications with forward secrecy are all DES (very weak) or 3DES (less weak).
2. AES ciphers for TLSv1 were originally specified in RFC 3268 in 2002, and did not make it into XP's SChannel implementation.  I believe this is why they aren't present in IE8/XP.  If the link is trustworthy, the only ciphers available on IE/XP are RC4 and 3DES, neither of which can be considered excellent choices today.
3. IE/XP does not truly offer forward secrecy because it doesn't support RSA modes with DHE, only DSS which has a 1024-bit limit; much of the TLS infrastructure has moved to require 2048-bit keys recently as 1024 is no longer considered adequate.
4. TLS specifications require one mandatory cipher, presumably to ensure minimum interoperability.  In TLSv1.2 (RFC 5246, published in 2008), that cipher is AES128-SHA.  Earlier versions including TLSv1 and TLSv1.1 listed 3DES-SHA.
5. Camellia cipher suites were defined in RFC 4132 in 2005.  That RFC has been superseded by RFC 5932 in 2010; the latter uses the SHA-2 hash family instead of SHA-1.
6. Camellia itself is expected to be of similar security to AES; current attacks on AES are better, but it's likely that AES is more widely studied.
7. SHA-2 hash family MACs were introduced in TLS v1.2.  It is believed that the older MD5/SHA-1 functions are still secure as used in TLS.  To the best of my knowledge, SHA-2 suites are only available when using TLSv1.2.
8. ECDHE suites are defined RFC 4492, from 2006; including a ClientHello extension to indicate support.
9. ECDHE is not required (though it is listed) in TLSv1.2, nor is usage of TLSv1.2 a requirement for using ECDHE.  Recent versions of Firefox support ECDHE suites in conjunction with TLSv1.  Older versions—Firefox 21/Fedora 19 for instance—do not.
10. Some browsers prefer alleged key length over other considerations, and prioritize 3DES with its "168" bit key over AES128.  It's actually designated by NIST as providing 80 bits of security, though it could be providing up to 112 bits.
11. The default cipher policy provided by AWS Elastic Load Balancers enables only SSLv3/TLSv1 and an extremely limited set of ciphers: AES128 and 256, 3DES, and RC4, with no forward secrecy suites.  (Suites are configurable in the AWS Console, but not cipher preference order, nor some renegotiation options.  Renegotiation settings are implicit in the choice of supporting, or not, the more-recent TLS versions.)

The Lavabit Problem: the Universal TLS Key

Lavabit refused to hand over the key to the whole kingdom for the U.S. Government to ostensibly capture the traffic of one user.  The judge ruled in the prosecution's favor in the resulting court case:

Judge Claude Hilton said that it was effectively Levison's fault that sites have only a single private SSL key.

Ars doesn't evaluate the truth of that, but technically, it could be accurate.  The Perfect Forward Secrecy modes of TLS—DHE and ECDHE—effectively generate a key per connection, authenticating the parameters used to create it with the server's certificate (which is in turn authenticated by the CA system.)  However, if Lavabit's servers were set up to allow RSA-only modes, then that configuration introduces the weakness.  Under RSA, the server's private key becomes the master private key, capable of decrypting any connection traffic in those modes, because that private key is used to encrypt all the traffic.

TLS: all those DH modes and PFS

Advice is easy to come by, explanation less so.  What are all these acronyms, and what makes them secure, or not?

devproxy

Today, I'm pleased to announce the release of devproxy!  It's an HTTP proxy server written in Go (atop github.com/elazarl/goproxy) for QA/testing purposes.  It intercepts requests directed to your production servers and transparently connects them to a staging server of your choice—including HTTPS (CONNECT) redirection.

This lets your staging server perfectly mirror production, including the hostnames and certificates in use, without needing to elevate permissions to edit /etc/hosts every time you want to switch between production and staging.  Instead, you can switch the proxy on/off in your browser; I use FoxyProxy.

I'd like to thank Elazar not only for writing goproxy (it made my life a lot easier) but also for modifying it to support what I needed to do in devproxy.  I'd also like to thank my boss for letting me release this as open source.

Broken By Default

This is why everything that uses openssl needs to configure a cipher list:

Mon 12:38 ~$ openssl version
OpenSSL 1.0.0g-fips 18 Jan 2012
Mon 12:38 ~$ openssl ciphers DEFAULT | sed -e 's/:/ /g'
... EDH-RSA-DES-CBC-SHA EDH-DSS-DES-CBC-SHA DES-CBC-SHA KRB5-DES-CBC-SHA KRB5-DES-CBC-MD5 EXP-EDH-RSA-DES-CBC-SHA EXP-EDH-DSS-DES-CBC-SHA EXP-DES-CBC-SHA EXP-RC2-CBC-MD5 EXP-KRB5-RC2-CBC-SHA EXP-KRB5-DES-CBC-SHA EXP-KRB5-RC2-CBC-MD5 EXP-KRB5-DES-CBC-MD5 EXP-RC4-MD5 EXP-KRB5-RC4-SHA EXP-KRB5-RC4-MD5

I cut the stronger ciphers from the output, leaving weak ones: everything that is EXP (pre-2000 export strength, 40- or 56-bit keys) or DES.  I decided to let triple-DES slide even though it's legacy and limited to 112 bits of security.  I also let KRB5 and PSK slide, even though my understanding is that they're useless on the public Internet, due to needing to share a Kerberos setup or key (resp.) with the client in advance of the connection being made.

Due to the weak ciphers being included by default, everyone needs to specially configure their server to gain true security.  This means that all admins who want to do it "right" must keep up on all advancements in the field of cryptography, and distinguish real breaks from crackpot allegations.  All admins who want it to "work" will just search the web and paste in whatever cipher suite they find, potentially leaving them vulnerable to BEAST.  Meanwhile, that library we trusted to provide security is doing its best to avoid giving it to us.

In other news: SSL Deployment Best Practices (PDF).

TLS (nee SSL) and SSH: A Compact Comparison

TLS and SSH rely on basically the same math for their connections.  The connection is initiated with asymmetric encryption, and part of that is exchanging (encrypted, of course) a symmetric session key for faster encryption of the main session traffic.

The main difference comes in how that initial asymmetric key is determined to be the one that legitimately belongs to the server, rather than an attacker who is trying to intercept communications.