Hacker News Reader

Comment by phlo | Hacker News Reader

This is great news. Furthering HTTPS adoption is the best way we have to combat pervasive surveillance, and we're making steps in the right direction before HTTP2's opportunistic encryption [1] will improve things on an even wider scale.

We'll also face some new challenges. Over the years, many users have learned to "look for the padlock" before entering their passwords. More sites moving to HTTPS will also increase the percentage of phishing/attack sites served over encrypted connections -- with the padlock to match. We'll need to renew our focus on training users to check for the correct domain name (and possibly an EV cert), or phishing sites with a cert from Let's Encrypt will become a real threat. Browsers are moving in the right direction, displaying https less conspicuously than before, and emphasizing connections with EV certs.

[1] http://httpwg.org/http-extensions/draft-ietf-httpbis-http2-e...

View on HN

Furthering HTTPS adoption is the best way we have to combat pervasive surveillance

No it isn't. HTTPS fights passive surveillance. The pervasive surveillance is already inside the HTTPS link, and deliberately so.

The actual best way we have to combat pervasive surveillance is to grow a spine and work to end the 1st and 3rd party surveillance our organizations implement, rather than just bitching about surveillance on the internet.

There are only a few actors positioned on the network that can passively perform surveillance pervasively (not just incidentally). My threat model extends beyond the NSA and ISPs. We've been taught to hate and fear them, but I'm sick of only thinking about the last crisis instead of focusing on the underlying problem.

Pervasive surveillance is also helped with browser fingerprinting, and Google, Facebook and so on are doing nothing to prevent that.

I'd like to see the default User-Agent header for HTTP2 be as short as "Chrome". Remove cookies, find ways to keep the identity of a user private.

Never gonna happen if we keep using Chrome.

Good idea. I wonder why the privacy-protecting Add-Ons (ABP, uBlock Origin) don't mask the UA by default.

On the other hand, trackers will probably just switch to detecting the capabilities of the browser using JS and then map each distinct set of capabilities to the matching browser version. In that scenario, an Add-On replacing your UA will actually increase trackability, as long as the majority of people aren't using it.

Because many sites (including most of Google's) won't work then ;)

Also it would be very easy to detect if a user is running an adblocker then.

uMatrix offers a feature to randomly pick a UA every 5 (configurable) minutes from a set of configurable UAs. This works, although GMail might complain about the UA being too old. Reloading GMail resolves it.

String matching is much simpler than timing and other means. Terse+honest agent strings could also avoid the confusing bloat seen in UAs like Edge.

> Over the years, many users have learned to "look for the padlock" before entering their passwords.

This is - unfortunately - bad advice. The padlock tells you that you're on the site that you are. But it doesn't tell you anything about the trustworthiness of the site.

If you're at https://evilhacker.com and you enter your password then evilhacker will get your password.

Absolutely. Which is why I think we still have a lot of work ahead of us, making users actually check the domain name, and the validated identity (for EV certs).

Having them use a passsword manager is a better apporach. Checking the domain name is weak to keming probiems.

...and password managers are weak to lots of problems [1], the least of which is malware stealing your password container plus the master key [2].

I'm still leaning towards the password manager side of the dilemma, but the situation isn't great on either.

[1] https://twitter.com/taviso/status/769378052254015488

[2] http://arstechnica.com/security/2014/11/citadel-attackers-ai...

> We'll need to renew our focus on training users

Totally useless, studies show that user just don't look or care. This after all the effort put into this.

The solution is new authentication that takes into account the domain.

This is exactly what has been done in the new FIDO standards, UAF and U2F. If you use U2F as a second factor on google, dropbox or github phishing is already a problem of the past.

These standards have now been given to the w3c and they are working on a further standard based on the fido ones.

https://fidoalliance.org/specifications/overview/

"is the best way we have to combat pervasive surveillance"

LOL, how fucking naive people are. HTTPS is good, yes. But HTTPS is also being fostered by service providers (Googles, Facebooks and other PRISM supporters) to try decrease revenue from operators and network providers, making sure they stay as random data pipes.

Google is probably the first company out there helping the government and other parties gather all your data, filter it and serve it to whomever is the highest bidder or for whichever obscure political reason.

If Google and the like were so big on privacy they'd do more to ensure that users can directly and privately talk to each other without intermediaries.

I agree. HTTPS is only good against your neighbor script kiddie and your isp injecting ads. Also now good if you want to support https2 features.

It's naive to think it's any good against states or sophisticated attackers.

Isn't HTTP2 supposed to be encrypted by default? I don't see that changing any time soon. I remember Firefox tried opportunistic HTTP1 encryption, but they rolled that back in a few days, and AFAIK, no one supports it.

In theory HTTP2 isn't required to use HTTPS, but in practice I don't think any browsers support HTTP2 without it.

A solution is to separate the encryption and authentication parts of SSL icons. Lets Encrypt and the likes get only the icon for ecrypted, the other old CA:s gets also the authenticated icon.

Ignoring the price tag, there's no difference between Let's Encrypt and "other old CAs". They both perform the same kind of validation for DV certificates. Some might even say Let's Encrypt does more than others, given that they support CAA.

Other types of certificates (such as EV, which attempt to verify the business entity requesting the certificate exists and is indeed requesting it) already get different treatment in most browsers (namely the organization's name being shown in a green box).

Do you think people who haven't studied crypto will understand the distinction between the two?

I'm still amazed at the fact that FCC regulations confuse encryption with authentication. On ham radio frequencies, you usually can't transmit encrypted traffic, because that's not what the frequency allocation is for. But for certain types of remote command of automated craft, you're allowed to encrypt the message because someone sending a tampered/spoofed message could crash your craft. Which completely confuses encryption and authentication! And that's from people whose entire job is to think about rulemaking for electronic communication.

Are you suggesting that signing a cleartext message would not involve encryption? Because I'm pretty sure the way "signing" works is to encrypt a hash of the message. So you need to send an encrypted message either way, even if it's a smaller one.

No, that's not how signing works - encryption is a function of a message and a public key, such that you can take the encrypted message and a private key and recover the cleartext. Since the public key is known to everyone, an attacker can modify the message, generate their own hash, and encrypt that with the public key, just as easily.

It's true that you can construct a signing scheme by using a decryption algorithm: treat the hash as if it were a ciphertext and "decrypt" it with the private key, then anyone can verify it by "encrypting" it with the public key. That way only the person with the private key can sign it, which is the direction you want. But this doesn't run afoul of the FCC's rules, because you're not obscuring the message; everyone has the public key.

If you're using so-called "textbook RSA" (i.e., the type of RSA you can explain on a whiteboard, with no hardening against real-world attacks), it's also true that the encryption and decryption operations are the same mathematical function. But you don't actually want to use textbook RSA, at the very least because of malleability (if you multiply two textbook-RSA ciphertexts, you get the same thing as if you'd decrypted them, multiplied the cleartexts, and encrypted that, except you don't need to know the private key), but also because of determinism, timing attacks, etc. Real-world RSA signature algorithms bear little resemblance to real-world RSA encryption or decryption algorithms.

Well... depends on the authentication scheme.

One authentication scheme which doesn't involve any encryption is HMAC with a shared secret key. Sure, you need the key to authenticate the message -- but that's perfectly fine in many situations.

It's 2016 and I still know no casual Internet user that looks for the green padlock before entering sensitive information. Heck, even many of my peers (developers, etc.) don't seem to either care or are ignorant to it. I don't think it's their fault, I believe it's more of an educational issue. Perhaps browsers should display a confirmation dialog when the user is trying to send some sensitive information over HTTP.

Chrome is going to start displaying an (admittedly easy-to-miss) warning in situations like that, starting in January: https://security.googleblog.com/2016/09/moving-towards-more-...

Firefox used to have a preference you could set:

  security.warn_submit_insecure

When set to true, Firefox would warn the user that the data they were about to send was not encrypted and would be sent over plain-text HTTP.

This setting was removed at some point (FF19, IIRC) and is currently (AFAICT) a NOP; cf. bug #799009, "Remove support for obsolete SSL-related warning prompts" [0]

[0]: https://bugzilla.mozilla.org/show_bug.cgi?id=799009

Reply on news.ycombinator.com