Hacker News Reader

Comment by jmillikin | Hacker News Reader

  > Should Firefox throw a generic warning for a 5 minute
  > expired certificate for Wikipedia?

Absolutely.

  > I want to use some basic encryption on my connection
  > rather than no encryption when visiting websites like
  > Wikipedia.

Then use Wikipedia's secure URL at https://secure.wikimedia.org/wikipedia/en/wiki/Main_Page

Encryption without authentication is useless. If mybank.com only supports encryption, I have no idea whether I'm actually connected to mybank.com , or to the guy running tcpdump in the next booth.

Firefox gets a lot of grief (from idiots) for refusing self-signed certificates by default, but it's a huge credit to their security team that they've resisted the pressure to ease up.

View on HN

The argument against self-signed certificates seems to be that people will get a false sense of security because they think that the connection is 'secure.' How about accepting the connection but not displaying the normal visual cues that say "this site is secure?" (e.g. the lock icon) Is that a significantly worse alternative?

The argument that encryption without authentication is useless seems to be too focused on the security of the connection. The larger the percentage of network traffic that is actually encrypted the less 'suspicious' encrypted connections look. In general, this is a state of affairs that we want to get to. Using encryption shouldn't make you stand out from the general population.

How is connecting to a site using HTTP any more secure than connecting to a site with HTTPS and a self-signed certificate so long as the user is not presented with any indication that the site is now 'secure?' Even better, how about having an icon that is always in one of two states: "secure" or "insecure." So now the user is presented with something that indicates "insecure" even when they are browsing over HTTP. This more accurately represents the state of affairs. The way browsers present security to the user currently is more along the lines of:

  HTTP => I can browse the web and login to Facebook
  HTTPS (CA-signed cert) => I can now use my credit card
  HTTPS (self-signed cert) => ZOMG! I'M BEING HACKED!

Encryption without authentication is useless.

It's mostly useless. Anyone trying to eavesdrop needs to expend slightly more resources, and needs to take the risk that there was some out-of-band authentication that they aren't aware of.

Firefox gets a lot of grief (from idiots) for refusing self-signed certificates by default, but it's a huge credit to their security team that they've resisted the pressure to ease up.

No, it mostly gets grief (from sane people) for not also refusing plain HTTP under the same pretenses.

An invalid certificate is far more likely to be an attack than a misconfigured server.

If Firefox silently accepted self-signed certificates, and presented the same UI as an unencrypted page, attackers could intercept requests to https://paypal.com/ and very few users would ever notice.

Additionally, automatically accepting self-signed certificates would render ideas like "HTTPS-only cookies" useless, because now the browser would happily send them to anyone who asks.

> An invalid certificate is far more likely to be an attack than a misconfigured server.

I don't believe that. I've run into tons of self signed/invalid certs that weren't attacks. If you're implicitly limiting your statement to large sites (paypal, amazon and the like) then you're probably right. But unqualified, it is definitely not the case.

Plain HTTP isn't lying to the end-user.

Would you support if browsers made password fields not-starred-out on HTTP sites? Just to make it clear that there is no implication of security there?

No, because that would be stupid.

The argument isn't whether encryption without authentication is useless, but whether encryption without authentication is significantly worse than useless and is therefore deserving of Firefox's awkward hoop-jumping UI. I'm not convinced.

I think there is potentially some middle ground to be found (e.g. a URL prefix which works over SSL but makes no implication of security) but clearly Mozilla decided that making it really irritating without any workaround was the best solution to the problem, regardless of any collatoral damage it causes.

This is not a hard concept to understand. You can't have secure encryption without trustworthy keys. Without the "authentication" functionality of SSL, you can't trust keys, because a man in the middle can simply swap them out of your session. When we say "you can't have encryption without authentication", we mean that every mechanism for agreeing on an AES key with a counterparty over the Internet relies on some form of authentication.

I understand the concept. I don't understand why you're pointing out the obvious to me, nor how your reply is a relevent response to my post.

I'm asking why an insecure SSL connection is worse than an insecure HTTP connection. If they are both completely insecure, why does Firefox turn one of them into a compete UI nightmare?

If the reasoning is that https:// somehow implies security, then the obvious and sensible solution is to create a new prefix for insecure SSL sites such as httpu://, and throw up a warning page when visiting the https version that links to the insecure SSL version.

I see this as being preferable to the awkward and annoying way Firefox treats self-signed certificates at the moment. I also suspect that had Mozilla taken the lead, the major browsers would have followed suit.

The plain HTTP connection doesn't claim to offer any security. You know not to give it your credit card number or password. What trust can you extend the "poorly encrypted" protocol?

You should give it the exact same amount of trust as a plain HTTP connection.

Which is exactly my point.

Then why the hell would you even use it?

The fact is, even if the browser so much as displays "https" in the addressbar, you are giving the unknowlegable user a form of positive feedback when none whatsoever is warrented. Strong netagive feedback is a much more appropriate solution.

It filters out some kinds of common attacks, e.g. most (all?) uses of Firesheep session-cookie snooping at coffee shops. Of course, for us nerd types https isn't really necessary for that, because I can just websurf over an ssh -D proxy to a VPS, to encrypt the coffee-shop side of the link.

You would use it because it makes encrypted traffic on the network the norm. It makes it impossible to decipher your traffic without an active deliberate security attack instead of a passive sniffing session. It means when a traffic sniffer happens on your traffic they will get (plain text, encrypted data) and they won't know whether the encrypted data is 'good' or 'bad' and will have an easier time with the plain text - the "just have to run faster than the other guy" approach.

It's not encrypted if the keys aren't secure.

Browsers are already having a really hard time making users of average proficiency understand SSL feedback and act wisely in response to warnings. Whatever special case they add to the UI to accomodate geeks using self-signed certs becomes yet another complexity that the normal user has to understand.

Also, consider that there are probably some users who think they understand the implications of trusting a self-signed cert while they actually do not, and the browser has no way of differentiating this.

Those people aren't "idiots," they're normal (non-geek) people. They just want to buy stuff on Amazon or whatever and not have their credit card number stolen.

Re-read my post -- the idiots are people who believe Firefox should accept self-signed certificates by default. Amazon has nothing to do with this.

Forget the Amazon example (there are plenty of legit sites that self-sign, like my school's online grading system). It scares the hell out of your average computer user, and it doesn't provide much gain.

The extension https everywhere auto-encrypts wikipedia

https://www.eff.org/https-everywhere

Encryption without authentication is useless. If mybank.com only supports encryption, I have no idea whether I'm actually connected to mybank.com , or to the guy running tcpdump in the next booth.

Well, of course encryption without authentication is useless for authentication.

It is still useful for encryption, though :-)

No, it's not. To encrypt data between two parties who don't know each other, both sides have to agree on a key. There is no protocol that does that securely in the presence of a man in the middle without a "tiebreaker"; the tiebreaker SSL PKI uses is certificates.

But doesn't (unauthenticated) encryption at least protect against eavesdroppers who don't have the ability to modify the stream, i.e. to mount a MITM attack?

"eavesdroppers who don't have the ability to modify the stream" are a nice fairytale, but they don't really exist in practice, with current network protocols. DNSSEC might change this, once it becomes universal.

What about Firesheep users? Surely there are many people who find it a lot easier to just capture some WiFi traffic via libpcap, WireShark or the like than to set up a fake WiFi access point, poison a DNS cache or mount other such attacks that would allow them to actually modify traffic.

Why are we talking about defenses that are defeated by just a couple lines of code? Firesheep could use pcap_write in addition to pcap_loop and redirect connections. What's the point of a defense that breaks Firesheep 1.0 only to fall to Firesheep 2.0?

Isn't that a bit like saying that it's pointless for policemen to wear bulletproof vests because there could always be a sniper aiming at their head?

Generally speaking, and regardless of today's protocols, surely passive eavesdropping is and will always remain easier to accomplish than actively mounting a MITM attack.

No. The opposite is true. It's actually easier to MITM in 2011 than it is to sniff passively; the MITM only needs to play packet games long enough to get the victim to connect to her.

Interesting, I didn't realize that. Since you're tptacek I'll take your word for it :-)

The only reason Firesheep doesn't modify traffic is because it doesn't have to. Faking DNS replies or similar would be trivial to add, were it needed.

The vulnerability here isn't "someone running Firesheep" - that's the exploit. The vulnerability here is "an open WiFi network is a completely trusted medium".

Given the recent EFF story about AT&T shunting all their traffic through NSA computers, I would say it most certainly exists in practice. Basic encryption with no authentication doesn't hold up at all to directed attacks, but it would definitely help with big siphoning attacks that are actually happening right now.

MITM attacks don't have to be directed. It's not technically challenging to mass-MITM a channel --- but you probably wouldn't do that, because you can just pick "interesting" connections (like, to Google Mail) to intercept.

Well, they are also a huge credit to preventing encryption from becoming the standard for all websites by ignoring 'idiots' and I'm talking non-banks like Wikipedia.

Are you happy to visit a John Doe blog with no encryption because he didn't want to pay for a certificate?

I'd rather have an unencrypted connection than encrypted to an unknown endpoint. If John Doe's blog is sensitive enough to require a secure connection, he can use one of the free certificate vendors like StartSSL.

Reply on news.ycombinator.com