5 ms·

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 HTT

by phlo 10y ago

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-encryption.html http://httpwg.org/http-extensions/draft-ietf-httpbis-http2-e...

thecopy 10y ago
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.
- pfg 10y ago
  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).
- geofft 10y ago
  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.
  - sp332 10y ago
    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.
    - geofft 10y ago
      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.
      - duskwuff 10y ago
        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.
hannob 10y ago
> 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 https://evilhacker.com and you enter your password then evilhacker will get your password.
- phlo 10y ago
  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).
  - afarrell 10y ago
    Having them use a passsword manager is a better apporach. Checking the domain name is weak to keming probiems.
    - phlo 10y ago
      ...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 https://twitter.com/taviso/status/769378052254015488 [2] http://arstechnica.com/security/2014/11/citadel-attackers-aim-to-steal-victims-master-passwords/ http://arstechnica.com/security/2014/11/citadel-attackers-ai...
ungatitolindo 10y ago
"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.
- angry-hacker 10y ago
  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.
Symbiote 10y ago
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.
- jhasse 10y ago
  Never gonna happen if we keep using Chrome.
- phlo 10y ago
  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.
  - jhasse 10y ago
    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.
  - cm3 10y ago
    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.
  - paulryanrogers 10y ago
    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.
theandrewbailey 10y ago
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.
- Ajedi32 10y ago
  In theory HTTP2 isn't required to use HTTPS, but in practice I don't think any browsers support HTTP2 without it.
art0rz 10y ago
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.
- Ajedi32 10y ago
  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-secure-web.html https://security.googleblog.com/2016/09/moving-towards-more-...
- jlgaddis 10y ago
  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 https://bugzilla.mozilla.org/show_bug.cgi?id=799009
forgottenpass 10y ago
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.
deleted 10y ago
[deleted]
nickik 10y ago
> 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/ https://fidoalliance.org/specifications/overview/

by phlo 10y ago

thecopy 10y ago

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.

pfg 10y ago
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).
geofft 10y ago
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.
- sp332 10y ago
  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.
  - geofft 10y ago
    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.
    - duskwuff 10y ago
      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.

hannob 10y ago

> 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 https://evilhacker.com and you enter your password then evilhacker will get your password.

phlo 10y ago
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).
- afarrell 10y ago
  Having them use a passsword manager is a better apporach. Checking the domain name is weak to keming probiems.
  - phlo 10y ago
    ...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 https://twitter.com/taviso/status/769378052254015488 [2] http://arstechnica.com/security/2014/11/citadel-attackers-aim-to-steal-victims-master-passwords/ http://arstechnica.com/security/2014/11/citadel-attackers-ai...

ungatitolindo 10y ago

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

angry-hacker 10y ago
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.

Symbiote 10y ago

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.

jhasse 10y ago
Never gonna happen if we keep using Chrome.
phlo 10y ago
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.
- jhasse 10y ago
  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.
- cm3 10y ago
  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.
- paulryanrogers 10y ago
  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.

theandrewbailey 10y ago

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.

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

art0rz 10y ago

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.

Ajedi32 10y ago
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-secure-web.html https://security.googleblog.com/2016/09/moving-towards-more-...
jlgaddis 10y ago
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 https://bugzilla.mozilla.org/show_bug.cgi?id=799009

forgottenpass 10y ago

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.

deleted 10y ago

[deleted]

nickik 10y ago

> 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/ https://fidoalliance.org/specifications/overview/