HTTPS Everywhere brings HTTPS almost everywhere [LWN.net]

HTTPS Everywhere brings HTTPS almost everywhere

Posted Jul 1, 2010 14:56 UTC (Thu) by cesarb (subscriber, #6266) [Link]

Perhaps DNSSEC plus RFC 4398.

HTTPS Everywhere brings HTTPS almost everywhere

Posted Jul 1, 2010 16:19 UTC (Thu) by cortana (subscriber, #24596) [Link]

That would be really cool. Such a system could totally replace the role of the CA in verifying that a public key is attached to a particular domain name.

I guess we'll still need CAs to perform detailed identity checks in order to issue the so-called 'extended validation' certificates, for high-security web sites.

I wonder how to get everyone to switch though? The existing CAs will lobby against any change. One advantage of getting certificates via DNSSEC would be that it would finally be possible to actually *revoke* a certificate, something which is basically impossible with the current system, since no one configures their browser to check the CRL of each and every CA that it trusts...

HTTPS Everywhere brings HTTPS almost everywhere

Posted Jul 2, 2010 4:20 UTC (Fri) by TRS-80 (subscriber, #1804) [Link]

RFC 5054 is also useful for certain websites, and IMAP particularly.

HTTPS Everywhere brings HTTPS almost everywhere

Posted Jul 4, 2010 4:45 UTC (Sun) by foom (subscriber, #14868) [Link]

Really? Cause I've looked at the SRP/TLS spec before, and for the life of me cannot figure out what the heck the point is.

Why is it useful to add password authentication to TLS? Both IMAP and HTTP already have ways of doing user authentication within the protocol itself. And, of course, you can use those mechanisms after setting up a TLS session if you want encryption.

Now, SRP *itself* looks like a nice replacement for CRAM-MD5, but why is it being proposed as an addition to TLS rather than as an additional mechanism in SASL? It seems like it'd be much more at home there...

HTTPS Everywhere brings HTTPS almost everywhere

Posted Jul 4, 2010 6:05 UTC (Sun) by TRS-80 (subscriber, #1804) [Link]

There is SASL/SRP too, but it's never been standardised in an RFC and isn't widely supported.

As for why SRP/TLS instead of TLS+SASL, the latter still requires a CA or self-signed certificates. HTTP auth isn't used much in the real world, and TLS/SRP isn't useful everywhere, since it requires a shared secret before establishing TLS. But when you have that, it's better than TLS+HTTP auth becuase again you don't require a CA, which is what cortana was asking about.

HTTPS Everywhere brings HTTPS almost everywhere

Posted Jul 4, 2010 19:15 UTC (Sun) by foom (subscriber, #14868) [Link]

Sure, HTTP auth isn't used *much*, but TLS client auth is barely used at all!

I find it really hard to imagine a website which could actually use TLS/SRP instead of a server certificate (if even any browsers supported it). You couldn't display content at all unless the user already has a valid login. No user registration, no "forgot password", etc. That just doesn't seem realistic.

The main issue with deployment of HTTP auth is that it has no way to "logout" or to timeout a session. SRP/TLS has the exact same problem. At least with HTTP auth, you can have some pages on your site require logging in, and others not require a login, and you can display content to the user without a login...

HTTPS Everywhere brings HTTPS almost everywhere

Posted Jul 5, 2010 4:41 UTC (Mon) by TRS-80 (subscriber, #1804) [Link]

I wasn't talking about HTTPS with client certs, I was talking about HTTPS with cookied login forms. And yes, there's no registration or forgotten password, hence why I said "shared secret" - it's suitable for environments where those are handled separately, like universities, companies etc.

HTTP auth can't be natively timed out (although there have been some nasty hacks that can work around it; I don't have examples to hand, but could find them if you want), but Firefox 3+ has UI for it, under "Clear Private Data..."