Hacker News Reader

Comment by Udo | Hacker News Reader

It's a description of how cookies work and why cookie heists are so devastating. As far as I can tell, the article doesn't contain any actual best practices. Furthermore, I think cookie stealing is a trivial problem and there is really only one solution: encryption.

The reason why encrypted connections are not the norm is a purely artificial one, because technically we could easily have the encryption aspect of HTTPS enabled by default, just as SSH does it today. We don't have that because browser makers and certificate authorities are happily running a money-making scheme that makes authentication mandatory if a site wants to use encryption. Droves of web developers and users have been brainwashed into thinking that encryption without an URL identity mechanism is somehow worse than having an unencrypted link.

However, this all has nothing to do with cookies, the connection is just incidental.

View on HN

There is no such thing as meaningful encryption without authentication; it's like a car with an engine but no steering wheel. Encryption without authentication is, at best, a trivial form of obfuscation (it's trivial because everybody knows how to reverse it).

Certificates aren't an elaborate money-making scheme. They're the tie breaking vote between Bank of America and the man-in-the-middle proxy pretending to be Bank of America.

Key agreement without some form of tie-breaker (be it key continuity, web-of-trust, or anchor keys, which is what SSL certificates use) is a fundamental problem familiar to anyone who has ever built any working cryptosystem. Among competent engineers, this isn't a debate. If you think anchor keys aren't the right solution to SSL, the onus is on you to suggest a viable alternative. "Nothing" is not a viable alternative; key agreement doesn't work with "nothing".

> They're the tie breaking vote between Bank of America and the man-in-the-middle proxy pretending to be Bank of America.

I'm not suggesting a new encryption standard for online banking, I want better default security for otherwise unprotected web traffic.

> There is no such thing as meaningful encryption without authentication; it's like a car with an engine but no steering wheel. Encryption without authentication is, at best, a trivial form of obfuscation (it's trivial because everybody knows how to reverse it).

In the context of my comment I was referring to the top-down cert authority structure (sorry if that wasn't clear), I didn't mean to imply that a webserver shouldn't have any certificate at all. I guess it comes down to disagreeing with you about self-signed certificates. I believe they would have been a good idea as a default mechanism for connecting to web servers and I still think they're way more secure than having nothing at all.

I believe that giving people exactly two choices, between cryptographic perfection and making transfers completely public, is wrong. And asserting that self-signed certificates are worse than no protection at all seems misguided to me. But in the end, you're the competent engineer and I'm just some guy posting inane comments on a message board over an unsecured link. And in any case, it's not like we'll change the way browser-based encryption works in the foreseeable future, so I kinda regret starting this whole discussion.

> If you think anchor keys aren't the right solution to SSL, the onus is on you to suggest a viable alternative. "Nothing" is not a viable alternative;

I'm sorry to say this but I suspect you are, maybe inadvertently, attacking a straw man here...

Self-signed certificates do not solve the problem and it's fairly straightforward to see why: anybody can create them. How does a browser know to pick your real self-signed certificate from the one generated by the man-in-the-middle proxy?

Every single free and commercial web security testing tool already does this on the fly. We are not talking about some complex, unlikely-to-occur threat. It's a pushbutton attack.

So... what's the point of a self-signed cert?

> I want better default security for otherwise unprotected web traffic.

The problem is that encryption without key agreement isn't better default security. It's worse because people will expect it to be secure when it cannot be.

You're probably thinking that it's really hard to get between you and random web servers, but you are sadly mistaken.

In many scenarios in which an attacker has access to your cookies he/she would also be able to perform a man-in-the-middle attack.

Encryption without confirming the identity of the other side is only slightly better than no encryption at all.

I agree that in theory it's a bad that thing many people think encryption with authentication is worse than no encryption at all, but in practice it doesn't matter. You cannot trust either of those options anyway.

I disagree. The simplest thing an attacker can do is sniffing the local traffic. It's a passive job, they don't even have to crack or break into anything, and what they're doing is essentially undetectable. Encryption helps against this, but not against man-in-the-middle attacks, that's true. However, those attacks are much more difficult to pull off than sniffing. Especially if you exchange a cert with your server just once, as you do in SSH. I do believe denying users access to encryption out of a fear of man-in-the-middle attacks and instead defaulting them to a completely unsecured link was and remains a dick move.

In case it wasn't obvious: I love SSH because it doesn't rely on cert authorities and because it's ridiculously easy to establish a reasonably secure connection; it empowers users and server admins to no end. Is it exploitable? Yes! But I do believe it's difficult and far less likely than exploiting an unencrypted connection. And I'll say it again: denying users access to this basic mechanism was not a nice maneuver.

Virtually nobody "sniffs local traffic" anymore, unless it's stub resolver traffic to bounce people to a MITM server. The MITM attack is the gold standard. It's not 1995 anymore and nobody is installing SunSniff on Sprintnet's backbone.

I think one aspect of encrypted connections not being the norm is the issue of client caching.

My experience of trying to cache on the client side, data ( from a php script ) requested via GET over https doesnt happen. This is done by design of the browsers as I believe they see it as the better of two evils. ( Not wanting to store secure data and then being attacked for that and losing market share ).

The approach I am using ( which is far from ideal ) is to make use of javascript, which can be cached.

True, but SSL certificates are pretty cheap nowadays, usually not much more expensive than the domain name.

Reply on news.ycombinator.com