User: Password:
|
|
Subscribe / Log in / New account

HTTPS Everywhere brings HTTPS almost everywhere

HTTPS Everywhere brings HTTPS almost everywhere

Posted Jul 2, 2010 4:20 UTC (Fri) by TRS-80 (subscriber, #1804)
In reply to: HTTPS Everywhere brings HTTPS almost everywhere by cortana
Parent article: HTTPS Everywhere brings HTTPS almost everywhere

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


(Log in to post comments)

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..."


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds