11 ms·

Opportunistic Encryption for Firefox

109 points by cpeterso 12y ago

Navarr 12y ago
This is very interesting. I think a better approach might be to separate encryption from trust. I'm thinking back to Chrome's announcement that they were considering making http:// http:// show some sort of warning. What if: * We make HTTP show up as "insecure" in browsers * We make HTTPS work with self-signed certificates, and display websites encrypted that way the same way we currently show http * We make HTTPS with Trust show up the way we currently show HTTPS * Keep EV Certs the same
- diafygi 12y ago
  Here's the Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1041087 https://bugzilla.mozilla.org/show_bug.cgi?id=1041087
- spectre256 12y ago
  I might be wrong,, but it seems like trust and encryption are fundamentally linked. For example, in the case of self-signed certificates, the browser knows it is encrypting a message to the holder of the self-signed certificate, but there's no information on who that is. The certificate sent could be changed, and there's no way to know something is wrong. Put another way, plain text is readable by anyone. Text properly encrypted to a known recipient is readable only by that recipient. But text encrypted to an unknown recipient is readable by only one entity, but that entity could be anyone, so it's equivalent to plain text.
  - pdkl95 12y ago
    Trust (authentication) and encryption are linked... iff your threat model includes defending against MitM attacks. For threat models that merely try to defend against trivial passive eavesdropping (such as bulk XKEYSCORE style surveillance or even just the local busybody that just learned how to use tcpdump), encryption alone is very useful. I strongly recommend using full authentication whenever possible, of course, but in the cases where that is not (yet?) practical, enabling auto-generated self-signed certificates for TLS should usually be a very simple change. Really, the only people that I expect would be against such an easy change are people doing NSA-style spying or businesses with a surveillance-based business model.
    - MichaelGG 12y ago
      The local busybody - how are they attacking you? On WiFi or arp poisoning scenarios, they can MitM with the same setup they're already using. If there was a big shift to encryption without verification, passive attacks could just start shifting to active ones. In most cases they're in place to do so. I suppose the major exception is optical splitter scenarios. But what's stopping them from replacing the splitter with another hop?
      - pdkl95 12y ago
        > If there was a big shift to encryption without verification Shift from WHAT? Remember, nobody is suggesting shifting anything from proper encryption, or changing the UI in any way that might mislead a user into thinking they were using a "secure" connection. This is a replacement for plaintext only. > But what's stopping them from replacing the splitter with another hop? Cost and complexity. Which is to say, if anybody really wants to throw a few megabucks at the problem, they will succeed, but that is not a contingency that some threat models worry about. I will refer to Dan Geer when he said[1] (and I suggest this is true for the corporation as well as government): The central dynamic internal to government is, and always has been, that the only way ... to control the many sub-units of government is by way of how much money [it] can hand out. ... Suppose, however, that surveillance becomes too cheap to meter, that is to say too cheap to limit through budgetary processes. This is what technology has done for the surveillance of plaintext. The marginal cost of recording "everybody"[2] went form about 1:1 in man-hours to practically free, largely because it is possible to log all the plaintext you want to disk, to be processed as needed (or to data mine). By raising the cost at all, we might be moving at least some types of eavesdropping back from "too cheap to limit". Make the eavesdropper work for it, instead of simply folding because they might decide to upgrade to a MitM. An even better question, though, is why are you so interested in keeping the internet in plaintext? [1] http://geer.tinho.net/geer.blackhat.6viii14.txt http://geer.tinho.net/geer.blackhat.6viii14.txt [2] for whatever definition of "everybody" you prefer
        MichaelGG 12y ago
        Some proposals were to warn about HTTP without OE, and then display the current HTTP plaintext UI for HTTP with OE. So long as there's no distinction to the end user UI so plaintext looks as good as OE, then I'm all for it.
- agwa 12y ago
  > * We make HTTP show up as "insecure" in browsers > * We make HTTPS work with self-signed certificates, and display websites encrypted that way the same way we currently show http Clear text and opportunistic encryption should have exactly the same UI. Security UIs are already too confusing, and we shouldn't introduce more complexity. Besides, one should never make a decision based on a clear text vs OE distinction, since OE is so easily defeated.
  - belorn 12y ago
    I guess this is why most administrators use telnet instead of ssh, since they don't have time to check ssh fingerprints... Well, not really. As it is, many people do make a decision based on a clear text vs OE. Now if just Firefox would store and check fingerprints of self-signed certificates, we would get the exact same benefit when telnet was replaced by ssh.
    - copsarebastards 12y ago
      Administrators are a much more sophisticated group than average users. Presenting telnet/SSH as equivalent to HTTP/HTTPS is silly because they have drastically different use cases.
      - wongarsu 12y ago
        I think his point is that ssh is just opportunistic encryption if you don't compare the fingerprint at the first connection. Anybody could just MitM your first connection to the server without you noticing, and then MitM every future connection as well. In a sense telnet/ssh is exactly like http/http_with_oe. And still we make a big deal out of the telnet/ssh difference while saying that http with OE is only marginally better than http. Of course it's not nearly that black and white because ssh stores the fingerprint, meaning you are safe if (and only if) your first connection wasn't intercepted.
    - IgorPartola 12y ago
      You don't check ssh fingerprints?
- higherpurpose 12y ago
  I think that's basically what the Chrome guys proposed.
  - Navarr 12y ago
    I think so too, but I don't recall them opening the doors for self-signed HTTPs as on-par with HTTP
- upofadown 12y ago
  >We make HTTPS work with self-signed certificates, and display websites encrypted that way the same way we currently show http Then how do you know you are getting any sort of encryption?
  - Navarr 12y ago
    Because the HTTP shows up as insecure, for one.
pavpanchekha 12y ago
This is a great step, one that I've been hoping for. Of course encryption without authentication is much worse than true encrypted transport (as in, with authentication), since it only prevents passive adversaries, but any sort of encrypted transport is better than plaintext. I'm also hoping this will ease the transition to TLS, since you can get it up and running without worrying about mixed-resource problems, then fix those one at a time.
- orthecreedence 12y ago
  I'd argue that the CA system is false authentication because it's fairly easy for the right players to tamper with. In that case, unauthenticated/encrypted transport is only a little less safe than "authenticated"/encrypted transport, but with the latter giving a higher illusion of safety than the former. The only real trust that would work is distributed trust. The CA system is kind of a joke. That said, yes, it does protect coffee shop HTTPS browsing better than a self-signed cert.
chimeracoder 12y ago
I'm really glad to see this. I really dislike that browsers seem to treat self-signed certificates as worse than plain HTTP (in that self-signed certificates cause a big scary yellow warning that looks similar to the big scary red warning for invalid certs). Self-signed certs are bad insofar as you can't prove that someone else isn't MITMing the connection and serving you an encrypted, but untrustworthy, proxy page. But with plain HTTP, you already have no guarantees that that isn't happening![0] If I understand it correctly, this seems to combine the best of both: encouraging the use of self-signed certificates over plain HTTP, while still rewarding verified certs (ie, signed by a trusted third party) over self-signed. [0] If you really care, you should use a CA-signed cert. But every attack that possible when using self-signed certs is not only possible when using plain HTTP, but much easier to execute, and also much easier to execute silently.
- tines 12y ago
  I won't defend it, but I can imagine that an argument for why self-signed certs could be worse than plain HTTP might be that if you're using HTTP, the communication isn't meant to be secure/trustworthy, but the presence of a certificate means that your communication is meant to be one or both, and since the cert is self-signed, it may not be either. This argument does presume that site administrators know what does and doesn't need to be confidential, which of course may not be the case. Some argue that all communication should be encrypted, but that's another issue.
  - Dylan16807 12y ago
    It's an argument made through misleading categories. Self-signed certs specifically are not an indication that the connection needs to be trustworthy, so treating it like HTTP is fine. If it's marked with HSTS, then fail it like HTTP. Don't show secure cookies. Easy.
    - Buge 12y ago
      But if someone clicks a link that says https:// https://, then the person who created that link wanted there to be authentication, so an error would be the correct behavior.
Dylan16807 12y ago
> 443 is a good choice :) If it's self signed, and going to throw massive warnings with a direct connection, shouldn't you use anything other than 443? Any subtleties I should be aware of?
- m_eiman 12y ago
  443 is more likely than a random port to be allowed through a firewall, for example.
- opejn 12y ago
  The main reason I would think it's a good choice is because if you decide to get a CA certificate later, you just drop it in and you're done; no additional configuration required. If you don't have a CA certificate, you're probably not advertising your https:// https:// URLs anyway, so unless search engines are aggressively looking/prioritizing for https transport, it wouldn't seem to hurt anything to run a self-signed certificate there.
  - Dylan16807 12y ago
    HTTPS everywhere. And I would not trust an entire site to go unindexed. There's a lot more to change if I want real HTTPS support. Changing a single port number is the least of my worries.
  - deleted 12y ago
    [deleted]
y0ghur7_xxx 12y ago
Does someone know how to set this up serverside? Does apache support this? I skimmed through the mod_spdy docs, but found nothing about opportunistic encrypion. This, together with TACK or Certificate Transparency could be a CA killer.
peterwwillis 12y ago
Opportunistic Encryption is harmful because people think it's actually useful. Here's the problem with opportunistic encryption: OE provides unauthenticated encryption over TLS for data that would otherwise be carried via clear text. This creates some confidentiality in the face of passive eavesdropping, You should never assume that 'eavesdropping' is passive. In almost every practical context of traffic interception, if you can read the transmission, you can write as well. If you're going to the trouble of installing some kind of tap, it makes more sense to make it read-write so you can actually do something with that intercepted connection. Collecting data is great, but hijacking is even better. and also provides you much better integrity protection for your data than raw TCP does when dealing with random network noise This is a red herring, and if you need real integrity is totally useless since it doesn't prevent an active attacker from corrupting the data once they've hijacked your unauthenticated connection. For the majority of plaintext traffic, a small amount of corruption is way more efficient to allow for than breaking down and re-creating a connection every time a single bit gets flipped. To use OE, you have to set up an SSL service in the first place, so just take the extra 15 minutes and make a real signed certificate. There is no such thing as "kind of" secure, after all. Encryption is intended to provide security. OE is not secure.
- Dylan16807 12y ago
  MitM takes more effort and is less common. You're only fooling yourself by thinking about it as black and white. How about "it's just as easy to MitM me, but I have reduced how common eavesdropping will be by 80%" I want that. And with how common ISP surveillance is, the number is probably much higher than 80. >There is no such thing as "kind of" secure, after all. If you really want to get absolute, then you have to admit that any computer you have purchased parts for is not secure. Levels of security exist.
  - peterwwillis 12y ago
    Of course levels of security exist. And OE is not on the spectrum of levels of security, because it is not a secure connection: http://www.techopedia.com/definition/13266/secure-connection http://www.techopedia.com/definition/13266/secure-connection It's an arms race. If I have sensitive data, you install a tap to capture it. If I begin obscuring the data from you rtap, you begin injecting traffic to unobscure it. If someone is trying to steal your data, they will not stop trying to steal it just because you applied ROT13 to it. Why do you think someone would just give up just because they now need to use an active attack? Active attacks are trivial once a tap is in place. We're not talking NSA research projects here; this shit has been going on since World War II. If they have a means to exploit your data, they will use it.
13throwaway 12y ago
The problem with allowing self-signed certificates has always been distinguishing if a site should be signed by a CA or not. Consider the follow situation: Alice sends Bob a link: http://example.com http://example.com Bob trusts Alice and now knows that example.com is probably ment to be accessed over HTTP. Now for the next example: Alice sends Bob a link: https://example.com https://example.com With the current implementation of browsers Bob knows that example.com should present a CA signed certificate. But what if example.com wants to encrypt their data, but for whatever reason uses a self-signed certificate? Some people say that Bob's browser should not display a "big scary" warning, but instead display a UI similar to when accessing a HTTP site. However, in this situation HTTPS has lost some meaning. I think http2 should work as follows: http2:// - encrypted, not verified https2:// - encrypted and verified This way the protocol still conveys the same level of information. However, if it were completely up to me, I would say ditch the CAs and use namecoin to verify certificates.
- JonathonW 12y ago
  That's more or less what OE does. It allows the browser to use HTTP/2 (and encryption) to connect to a site, but keeps the user experience the same as unencrypted HTTP. That's why self-signed certificates work in this context; the identity of the server's not supposed to be validated (unencrypted HTTP can't validate server identities), so the browser can accept a self-signed certificate without warning. There's no change to how certificates are authenticated when accessing a site via an https:// https:// URL.
- deleted 12y ago
  [deleted]
- Kalium 12y ago
  > However, if it were completely up to me, I would say ditch the CAs and use namecoin to verify certificates. Please, please, please, please no. Any kind of blockchain is far too vulnerable to attacks here to be a good source of authority.
quonn 12y ago
This is good, but still not a good as a service that requires at least an unauthenticated encryption. The problem is that the attacker has to be active, but very little effort is needed to break this without the user noticing - it's enough to inject some packets to disrupt the TLS connection. However, for HTTP it's the best thing possible at this point.
teddyh 12y ago
This is only for HTTP/2. If could have been for HTTP/1.1 also, if there had existed a registered ALPN name for “HTTP/1.1 with TLS”. As it is now, HTTP/2 has both variants, but HTTP/1.1 stands alone¹. ① https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids https://www.iana.org/assignments/tls-extensiontype-values/tl...
- patrickmcmanus 12y ago
  fwiw the h1 barrier was the lack of a scheme indication in an h1 transaction - not really the alpn ids (which can always be registered if need be). But without a scheme the server just needs to infer http vs https from the port/address and that wouldn't work with alt-svc
  - teddyh 12y ago
    Since this is a backport of a new feature from a new protocol to its older predecesor protocol, it is not necessary to be so wary of slightly uglier features. Simply having “Alt-Svc: http/1.1:443” imply HTTPS would do fine to solve this specific problem, and I doubt anyone would really have a problem with it.
zaroth 12y ago
Please, please, can we have the same for WiFi?! Trade a key with the AP when you first associate, and be done with it. The entire concept of a WiFi password is a *%^$ waste of time.
deleted 12y ago
[deleted]
jesrui 12y ago
Since the request and response sizes can reveal what public page you are browsing over https, OE in the proposed form would not prevent user tracking: http://sysd.org/stas/node/220 http://sysd.org/stas/node/220
upofadown 12y ago
This is a neat idea, but we really need to define a standard for self signed certificates. Something like certificate pinning should be mandatory. It should be done in a way so there is no confusion with a connection with identity protection but at the same time it is essential that the user knows they are at least getting the protection of the self signed certificate. Perhaps we need something like a httpq:// resource identifier. For bonus points such a standard should incorporate a web of trust system that can not be overridden by a bogus certificate in the regular system. Ideally a self signed certificate provided by someone you can physically visit should be more secure than what we have now. Added: I guess my point is that we are thinking about this backwards. A verified self signed certificate is the gold standard, not some inferior alternative. I should be able to walk into my bank and then walk out with a certificate on a USB key that can not be messed with. If we are going to change things we should strive to end up with the possibility of something better than what we have now.

109 points by cpeterso 12y ago

This is very interesting. I think a better approach might be to separate encryption from trust. I'm thinking back to Chrome's announcement that they were considering making http:// http:// show some sort of warning. What if: * We make HTTP show up as "insecure" in browsers * We make HTTPS work with self-signed certificates, and display websites encrypted that way the same way we currently show http * We make HTTPS with Trust show up the way we currently show HTTPS * Keep EV Certs the same

diafygi 12y ago
Here's the Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1041087 https://bugzilla.mozilla.org/show_bug.cgi?id=1041087
spectre256 12y ago
I might be wrong,, but it seems like trust and encryption are fundamentally linked. For example, in the case of self-signed certificates, the browser knows it is encrypting a message to the holder of the self-signed certificate, but there's no information on who that is. The certificate sent could be changed, and there's no way to know something is wrong. Put another way, plain text is readable by anyone. Text properly encrypted to a known recipient is readable only by that recipient. But text encrypted to an unknown recipient is readable by only one entity, but that entity could be anyone, so it's equivalent to plain text.
- pdkl95 12y ago
  Trust (authentication) and encryption are linked... iff your threat model includes defending against MitM attacks. For threat models that merely try to defend against trivial passive eavesdropping (such as bulk XKEYSCORE style surveillance or even just the local busybody that just learned how to use tcpdump), encryption alone is very useful. I strongly recommend using full authentication whenever possible, of course, but in the cases where that is not (yet?) practical, enabling auto-generated self-signed certificates for TLS should usually be a very simple change. Really, the only people that I expect would be against such an easy change are people doing NSA-style spying or businesses with a surveillance-based business model.
  - MichaelGG 12y ago
    The local busybody - how are they attacking you? On WiFi or arp poisoning scenarios, they can MitM with the same setup they're already using. If there was a big shift to encryption without verification, passive attacks could just start shifting to active ones. In most cases they're in place to do so. I suppose the major exception is optical splitter scenarios. But what's stopping them from replacing the splitter with another hop?
    - pdkl95 12y ago
      > If there was a big shift to encryption without verification Shift from WHAT? Remember, nobody is suggesting shifting anything from proper encryption, or changing the UI in any way that might mislead a user into thinking they were using a "secure" connection. This is a replacement for plaintext only. > But what's stopping them from replacing the splitter with another hop? Cost and complexity. Which is to say, if anybody really wants to throw a few megabucks at the problem, they will succeed, but that is not a contingency that some threat models worry about. I will refer to Dan Geer when he said[1] (and I suggest this is true for the corporation as well as government): The central dynamic internal to government is, and always has been, that the only way ... to control the many sub-units of government is by way of how much money [it] can hand out. ... Suppose, however, that surveillance becomes too cheap to meter, that is to say too cheap to limit through budgetary processes. This is what technology has done for the surveillance of plaintext. The marginal cost of recording "everybody"[2] went form about 1:1 in man-hours to practically free, largely because it is possible to log all the plaintext you want to disk, to be processed as needed (or to data mine). By raising the cost at all, we might be moving at least some types of eavesdropping back from "too cheap to limit". Make the eavesdropper work for it, instead of simply folding because they might decide to upgrade to a MitM. An even better question, though, is why are you so interested in keeping the internet in plaintext? [1] http://geer.tinho.net/geer.blackhat.6viii14.txt http://geer.tinho.net/geer.blackhat.6viii14.txt [2] for whatever definition of "everybody" you prefer
      - MichaelGG 12y ago
        Some proposals were to warn about HTTP without OE, and then display the current HTTP plaintext UI for HTTP with OE. So long as there's no distinction to the end user UI so plaintext looks as good as OE, then I'm all for it.
agwa 12y ago
> * We make HTTP show up as "insecure" in browsers > * We make HTTPS work with self-signed certificates, and display websites encrypted that way the same way we currently show http Clear text and opportunistic encryption should have exactly the same UI. Security UIs are already too confusing, and we shouldn't introduce more complexity. Besides, one should never make a decision based on a clear text vs OE distinction, since OE is so easily defeated.
- belorn 12y ago
  I guess this is why most administrators use telnet instead of ssh, since they don't have time to check ssh fingerprints... Well, not really. As it is, many people do make a decision based on a clear text vs OE. Now if just Firefox would store and check fingerprints of self-signed certificates, we would get the exact same benefit when telnet was replaced by ssh.
  - copsarebastards 12y ago
    Administrators are a much more sophisticated group than average users. Presenting telnet/SSH as equivalent to HTTP/HTTPS is silly because they have drastically different use cases.
    - wongarsu 12y ago
      I think his point is that ssh is just opportunistic encryption if you don't compare the fingerprint at the first connection. Anybody could just MitM your first connection to the server without you noticing, and then MitM every future connection as well. In a sense telnet/ssh is exactly like http/http_with_oe. And still we make a big deal out of the telnet/ssh difference while saying that http with OE is only marginally better than http. Of course it's not nearly that black and white because ssh stores the fingerprint, meaning you are safe if (and only if) your first connection wasn't intercepted.
  - IgorPartola 12y ago
    You don't check ssh fingerprints?
higherpurpose 12y ago
I think that's basically what the Chrome guys proposed.
- Navarr 12y ago
  I think so too, but I don't recall them opening the doors for self-signed HTTPs as on-par with HTTP
upofadown 12y ago
>We make HTTPS work with self-signed certificates, and display websites encrypted that way the same way we currently show http Then how do you know you are getting any sort of encryption?
- Navarr 12y ago
  Because the HTTP shows up as insecure, for one.

pavpanchekha 12y ago

This is a great step, one that I've been hoping for. Of course encryption without authentication is much worse than true encrypted transport (as in, with authentication), since it only prevents passive adversaries, but any sort of encrypted transport is better than plaintext. I'm also hoping this will ease the transition to TLS, since you can get it up and running without worrying about mixed-resource problems, then fix those one at a time.

orthecreedence 12y ago
I'd argue that the CA system is false authentication because it's fairly easy for the right players to tamper with. In that case, unauthenticated/encrypted transport is only a little less safe than "authenticated"/encrypted transport, but with the latter giving a higher illusion of safety than the former. The only real trust that would work is distributed trust. The CA system is kind of a joke. That said, yes, it does protect coffee shop HTTPS browsing better than a self-signed cert.

chimeracoder 12y ago

I'm really glad to see this. I really dislike that browsers seem to treat self-signed certificates as worse than plain HTTP (in that self-signed certificates cause a big scary yellow warning that looks similar to the big scary red warning for invalid certs). Self-signed certs are bad insofar as you can't prove that someone else isn't MITMing the connection and serving you an encrypted, but untrustworthy, proxy page. But with plain HTTP, you already have no guarantees that that isn't happening![0] If I understand it correctly, this seems to combine the best of both: encouraging the use of self-signed certificates over plain HTTP, while still rewarding verified certs (ie, signed by a trusted third party) over self-signed. [0] If you really care, you should use a CA-signed cert. But every attack that possible when using self-signed certs is not only possible when using plain HTTP, but much easier to execute, and also much easier to execute silently.

tines 12y ago
I won't defend it, but I can imagine that an argument for why self-signed certs could be worse than plain HTTP might be that if you're using HTTP, the communication isn't meant to be secure/trustworthy, but the presence of a certificate means that your communication is meant to be one or both, and since the cert is self-signed, it may not be either. This argument does presume that site administrators know what does and doesn't need to be confidential, which of course may not be the case. Some argue that all communication should be encrypted, but that's another issue.
- Dylan16807 12y ago
  It's an argument made through misleading categories. Self-signed certs specifically are not an indication that the connection needs to be trustworthy, so treating it like HTTP is fine. If it's marked with HSTS, then fail it like HTTP. Don't show secure cookies. Easy.
  - Buge 12y ago
    But if someone clicks a link that says https:// https://, then the person who created that link wanted there to be authentication, so an error would be the correct behavior.

Dylan16807 12y ago

> 443 is a good choice :) If it's self signed, and going to throw massive warnings with a direct connection, shouldn't you use anything other than 443? Any subtleties I should be aware of?

m_eiman 12y ago
443 is more likely than a random port to be allowed through a firewall, for example.
opejn 12y ago
The main reason I would think it's a good choice is because if you decide to get a CA certificate later, you just drop it in and you're done; no additional configuration required. If you don't have a CA certificate, you're probably not advertising your https:// https:// URLs anyway, so unless search engines are aggressively looking/prioritizing for https transport, it wouldn't seem to hurt anything to run a self-signed certificate there.
- Dylan16807 12y ago
  HTTPS everywhere. And I would not trust an entire site to go unindexed. There's a lot more to change if I want real HTTPS support. Changing a single port number is the least of my worries.
- deleted 12y ago
  [deleted]

y0ghur7_xxx 12y ago

Does someone know how to set this up serverside? Does apache support this? I skimmed through the mod_spdy docs, but found nothing about opportunistic encrypion. This, together with TACK or Certificate Transparency could be a CA killer.

peterwwillis 12y ago

Opportunistic Encryption is harmful because people think it's actually useful. Here's the problem with opportunistic encryption: OE provides unauthenticated encryption over TLS for data that would otherwise be carried via clear text. This creates some confidentiality in the face of passive eavesdropping, You should never assume that 'eavesdropping' is passive. In almost every practical context of traffic interception, if you can read the transmission, you can write as well. If you're going to the trouble of installing some kind of tap, it makes more sense to make it read-write so you can actually do something with that intercepted connection. Collecting data is great, but hijacking is even better. and also provides you much better integrity protection for your data than raw TCP does when dealing with random network noise This is a red herring, and if you need real integrity is totally useless since it doesn't prevent an active attacker from corrupting the data once they've hijacked your unauthenticated connection. For the majority of plaintext traffic, a small amount of corruption is way more efficient to allow for than breaking down and re-creating a connection every time a single bit gets flipped. To use OE, you have to set up an SSL service in the first place, so just take the extra 15 minutes and make a real signed certificate. There is no such thing as "kind of" secure, after all. Encryption is intended to provide security. OE is not secure.

Dylan16807 12y ago
MitM takes more effort and is less common. You're only fooling yourself by thinking about it as black and white. How about "it's just as easy to MitM me, but I have reduced how common eavesdropping will be by 80%" I want that. And with how common ISP surveillance is, the number is probably much higher than 80. >There is no such thing as "kind of" secure, after all. If you really want to get absolute, then you have to admit that any computer you have purchased parts for is not secure. Levels of security exist.
- peterwwillis 12y ago
  Of course levels of security exist. And OE is not on the spectrum of levels of security, because it is not a secure connection: http://www.techopedia.com/definition/13266/secure-connection http://www.techopedia.com/definition/13266/secure-connection It's an arms race. If I have sensitive data, you install a tap to capture it. If I begin obscuring the data from you rtap, you begin injecting traffic to unobscure it. If someone is trying to steal your data, they will not stop trying to steal it just because you applied ROT13 to it. Why do you think someone would just give up just because they now need to use an active attack? Active attacks are trivial once a tap is in place. We're not talking NSA research projects here; this shit has been going on since World War II. If they have a means to exploit your data, they will use it.

13throwaway 12y ago

The problem with allowing self-signed certificates has always been distinguishing if a site should be signed by a CA or not. Consider the follow situation: Alice sends Bob a link: http://example.com http://example.com Bob trusts Alice and now knows that example.com is probably ment to be accessed over HTTP. Now for the next example: Alice sends Bob a link: https://example.com https://example.com With the current implementation of browsers Bob knows that example.com should present a CA signed certificate. But what if example.com wants to encrypt their data, but for whatever reason uses a self-signed certificate? Some people say that Bob's browser should not display a "big scary" warning, but instead display a UI similar to when accessing a HTTP site. However, in this situation HTTPS has lost some meaning. I think http2 should work as follows: http2:// - encrypted, not verified https2:// - encrypted and verified This way the protocol still conveys the same level of information. However, if it were completely up to me, I would say ditch the CAs and use namecoin to verify certificates.

JonathonW 12y ago
That's more or less what OE does. It allows the browser to use HTTP/2 (and encryption) to connect to a site, but keeps the user experience the same as unencrypted HTTP. That's why self-signed certificates work in this context; the identity of the server's not supposed to be validated (unencrypted HTTP can't validate server identities), so the browser can accept a self-signed certificate without warning. There's no change to how certificates are authenticated when accessing a site via an https:// https:// URL.
deleted 12y ago
[deleted]
Kalium 12y ago
> However, if it were completely up to me, I would say ditch the CAs and use namecoin to verify certificates. Please, please, please, please no. Any kind of blockchain is far too vulnerable to attacks here to be a good source of authority.

quonn 12y ago

This is good, but still not a good as a service that requires at least an unauthenticated encryption. The problem is that the attacker has to be active, but very little effort is needed to break this without the user noticing - it's enough to inject some packets to disrupt the TLS connection. However, for HTTP it's the best thing possible at this point.

teddyh 12y ago

This is only for HTTP/2. If could have been for HTTP/1.1 also, if there had existed a registered ALPN name for “HTTP/1.1 with TLS”. As it is now, HTTP/2 has both variants, but HTTP/1.1 stands alone¹. ① https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids https://www.iana.org/assignments/tls-extensiontype-values/tl...

patrickmcmanus 12y ago
fwiw the h1 barrier was the lack of a scheme indication in an h1 transaction - not really the alpn ids (which can always be registered if need be). But without a scheme the server just needs to infer http vs https from the port/address and that wouldn't work with alt-svc
- teddyh 12y ago
  Since this is a backport of a new feature from a new protocol to its older predecesor protocol, it is not necessary to be so wary of slightly uglier features. Simply having “Alt-Svc: http/1.1:443” imply HTTPS would do fine to solve this specific problem, and I doubt anyone would really have a problem with it.

zaroth 12y ago

Please, please, can we have the same for WiFi?! Trade a key with the AP when you first associate, and be done with it. The entire concept of a WiFi password is a *%^$ waste of time.

deleted 12y ago

[deleted]

jesrui 12y ago

Since the request and response sizes can reveal what public page you are browsing over https, OE in the proposed form would not prevent user tracking: http://sysd.org/stas/node/220 http://sysd.org/stas/node/220

upofadown 12y ago

This is a neat idea, but we really need to define a standard for self signed certificates. Something like certificate pinning should be mandatory. It should be done in a way so there is no confusion with a connection with identity protection but at the same time it is essential that the user knows they are at least getting the protection of the self signed certificate. Perhaps we need something like a httpq:// resource identifier. For bonus points such a standard should incorporate a web of trust system that can not be overridden by a bogus certificate in the regular system. Ideally a self signed certificate provided by someone you can physically visit should be more secure than what we have now. Added: I guess my point is that we are thinking about this backwards. A verified self signed certificate is the gold standard, not some inferior alternative. I should be able to walk into my bank and then walk out with a certificate on a USB key that can not be messed with. If we are going to change things we should strive to end up with the possibility of something better than what we have now.