9 ms·

Users/user agents need to know whether to expect a connection to be secure. Unfortunately, you can't necessarily trust any random link you follow to reliably te

by btrask 10y ago

Users/user agents need to know whether to expect a connection to be secure. Unfortunately, you can't necessarily trust any random link you follow to reliably tell you. If I can get you to use HTTP when you should've used HTTPS, I might be able to sniff your traffic. If I can get you to use HTTPS when you should've used HTTP, it might be a DoS. Incidentally, this is the same problem as public key distribution. You need a trusted channel to receive public keys, and a trusted channel to know whether to use a public key. Why can't these be the same channel? Right now we have HSTS preloading[1] for the latter, but in that case why not preload certificates (or hashes thereof) too? Then we can finally cut out the middle-men and realize the truth: that the browser is the ultimate certificate authority. [1] https://hstspreload.appspot.com/ https://hstspreload.appspot.com/

dredmorbius 10y ago
Incorrect on public keys. You do not need a trusted channel to receive a key. You could receive one via smoke signal, carrier pigeon, or billboard. Existing key distribution systems may or may not be encrypted, but the reason for encrypting the channel is far more to protect the interests of the requestor than the integrity of the key itself. That last is independent of the key distribution channel. What matters is that the web of trust associated with that key is sound (that is, you have assurance that the key belongs to whom you think it does), and that the integrity of the private key has been maintained. The first of those problems is difficult, but not intractable. The second problem is rather difficult, especially in the case of persistent data, though the core requirement is that the key was valid when a message was generated, if you're looking at the sender of information. For your own information, you are relying on the recipient to maintain integrity over their private (decryption) key going forward, such that the data you'd transmitted remains encrypted against all others. The first problem you point out, that any encrypted channel is not necessarily a secure channel, is valid, though given your misunderstanding on subsequent points I'm not sure how well that applies to this discussion (I still need to RTFA).
- btrask 10y ago
  I said trusted, not encrypted. I wasn't talking about private keys at all. I think I understand the issues involved. Thanks though.
  - dredmorbius 10y ago
    And I still disagree on that point. Maybe I misunderstand (though I also think I understand teh issues involved pretty well), or maybe one or the other or both of us are communicating poorly. How would you distinguish a trusted, encrypted, and untrusted channels, say?
    - btrask 10y ago
      In the context of sharing public keys, I'd say you merely need authentication. Web of Trust being one possible mechanism. This isn't a particularly advanced topic. Relevant to my original post, information about whether the connection should be encrypted also merely needs to be authenticated, not encrypted itself. Of course, the HSTS preloading site uses HTTPS (with encryption) because it's easy and why not.
      - dredmorbius 10y ago
        Thanks. So re keysharing, authentication is a form of secure channel. I'm reading the auth and channel as independent. Auth is something of a metachannel, perhaps.
        btrask 10y ago
        Fair enough. :)
- michael_storm 10y ago
  > Existing key distribution systems may or may not be encrypted, but the reason for encrypting the channel is far more to protect the interests of the requestor than the integrity of the key itself. btrask wasn't saying that encryption is necessary for key distribution; he/she was saying that HTTPS guarantees identity and integrity, both of which are necessary to trust a key. > What matters is that the web of trust associated with that key is sound (that is, you have assurance that the key belongs to whom you think it does), and that the integrity of the private key has been maintained. That's a possible alternative to btrask's proposal, though you're equating "assurance that the key belongs to whom you think it does" with "web of trust". btrask's proposal is a special case of that, in which the web of trust is simply the sender. > The first problem you point out, that any encrypted channel is not necessarily a secure channel Correct, but not what btrask said. The first problem he pointed out was the fact that clients need to know whether a host expects secure communication before ever connecting to it. > though given your misunderstanding on subsequent points I'm not sure how well that applies to this discussion That's not very nice.
  - dredmorbius 10y ago
    Clarifying my own post: I'm insisting that neither a trusted or an ecrypted channel are necessary. I said that an encrypted channel could be used, and that it might not be, but that if used encryption would largely serve as a protection to the requestor, who might otherwise be subject to traffic and/or interest analysis based on the specific keys they requested, which could be presumed to be of interest, or signing keys (I'm thinking PGP protocol here) of keys of interest. Either piece of information would reduce search space for an Eve. I'm not equating trust of keys to web of trust, I'm stating that in existing (PKI/PGP) protocols, that is the assurance mechanism. And it is independent of either trust OR encryption of the key delivery channel itself. There seems to be a rather profound difficulty in distinguishing what I've said with what I've said btrask said. I'm not sure how I could be clearer, but I'm open to pointers.
    - michael_storm 10y ago
      You're both right. I only replied because you responded to points that btrask hadn't made, then claimed he/she misunderstood the topic.
- nicky0 10y ago
  What if someone intercepts the carrier pigeon and swaps in a different public key of their own?
  - dredmorbius 10y ago
    Then the signatures don't match, or the fingerprint is wrong. If you're relying on long-term data access, messages encrypted against or signed by the true key don't match. This is an area in which PGP and SSH differ markedly. PGP is used to encrypt and authenticate data which tends to persist, SSH data used only in session. While both can use long-lived keypairs, it's the PGP keys you're more likely to notice changing (though SSH cclients tend to report this happening). Yes, that means verifying your keys, and probably through an out-of-band method.
iancarroll 10y ago
Chrome does preload public key pins for large sites, not that it's the ultimate solution to what you describe.
- mintplant 10y ago
  Firefox also does this.
winteriscoming 10y ago
>> If I can get you to use HTTPS when you should've used HTTP, it might be a DoS. Can you explain what you mean by this? Genuinely curious to know how it can lead to DoS?
- marvy 10y ago
  the only way I can think of is if the site doesn't support https
- pcl 10y ago
  One way would be to re-direct cacheable assets to HTTPS, thus foiling edge caching and increasing load on the origin server. In general, caching is a big problem with the naive approach to "HTTPS everywhere." A mechanism to deliver signed cacheable payloads would be great, so that static assets etc. can continue to be edge-cached.
  - breatheoften 10y ago
    That seems like a good idea -- a simple scheme where the browser validates every http response from a particular domain against a key specified in that domain's SSL cert (if the appropriate field is present in the https cert) -- seems like it would work well?
    - anewhnaccount 10y ago
      This is what MEGA does. See: https://github.com/meganz/webclient/blob/master/secureboot.js https://github.com/meganz/webclient/blob/master/secureboot.j...
  - continuational 10y ago
    It would still need to be encrypted, or I could tell a lot about what you're doing on the site by looking at what cacheable resources you fetch.
    - XorNot 10y ago
noja 10y ago
> Users/user agents need to know whether to expect a connection to be secure. Why not expect it to be secure? Connect to https before http.
- markild 10y ago
  Behavior like that needs to come with a huge warning label. It would be trivial for any man-in-the-middle to block https and server http.
  - AstralStorm 10y ago
    This is exactly why browsers warn about such redirects. That said, this reminds me of a similar discussion on mail servers. There, STARTTLS sees much more use. The main problem is preventing downgrade attacks. With mail it is easy to just remember the setting for every server. Not so with websites.
    - michaelt 10y ago
      I've seen quite a bit of criticism of it for mail servers [1] because an attacker can simply block the 'STARTTLS' message and (many) clients will silently accept that. [1] https://www.agwa.name/blog/post/starttls_considered_harmful https://www.agwa.name/blog/post/starttls_considered_harmful
  - hello_there 10y ago
    They could display that same "this page is not secure"-page that they display on broken certificates.
- chrisseaton 10y ago
  I'm not sure you can assume that the same URL with https will be the same content as at http. It could be an entirely different site that you may not have wanted.
- ATsch 10y ago
  what if you block the https request in some way? You can now force an Insecure connection.
belorn 10y ago
> If I can get you to use HTTP when you should've used HTTPS, I might be able to sniff your traffic That is not worst case scenario. If someone can force http, they can also inject malicious code into the stream and do anything from bank transfers to create botnets. With the worst case scenario of always https being DoS, and worst case scenario of allowing http is code injection, I would prefer deprecating http in favor of https.
- derefr 10y ago
  There are a few use-cases for standalone unencrypted HTTP. The two big ones: • HTTP is redundant and costly when you're already in some other tunnel: a pre-negotiated IPSec tunnel for port 80 traffic to a given peer (e.g. a load balancer to its backend); talking directly to an HTTP proxy sitting on the jump box you're VPNed or SSH tunnelled into; etc. • HTTP is actually a great wire protocol for non-networked RPC, such as between Nginx and your application server, running on the same box, over a Unix socket. FCGI, WSGI, etc. are just half-assed implementations of HTTP; you may as well just use HTTP. (Though the non-front-of-line-blocking benefits of HTTP2 RPC would be even better here, for green-threaded runtimes that can C10K.) I do agree, though, that unencrypted HTTP can likely be deprecated for web browsers. The browser-addressible web is really a pretty strictly-bounded subset of the web as a whole, and we should strive to make it safe to browse. That being said, such statements put me in mind of a future where your browser literally is not allowed to talk to all those old servers from 1997 that are still hosting whatever they were hosting back then. Instead, all requests for those "legacy" domains that nobody's updating any more would have to go to some trusted mirroring site served over HTTPS, like the Internet Archive. (The spidering logic for such "legacy mirroring" would also have to be slightly different from today's "latest mirroring" logic: if the IA's spider got MITMed to see something else, it should "doubt" the new version based on how long the previous site endured without change, and if its confidence is low enough, just continue showing people the old version.) Is that a future we want? I'm honestly not sure.
posterboy 10y ago
Hen and Egg, where do you get the secure browser from?
- Tepix 10y ago
  It's bundled with your OS. If you don't like the bundled one you can use it to download a different one using HTTPS.

by btrask 10y ago

dredmorbius 10y ago

Incorrect on public keys. You do not need a trusted channel to receive a key. You could receive one via smoke signal, carrier pigeon, or billboard. Existing key distribution systems may or may not be encrypted, but the reason for encrypting the channel is far more to protect the interests of the requestor than the integrity of the key itself. That last is independent of the key distribution channel. What matters is that the web of trust associated with that key is sound (that is, you have assurance that the key belongs to whom you think it does), and that the integrity of the private key has been maintained. The first of those problems is difficult, but not intractable. The second problem is rather difficult, especially in the case of persistent data, though the core requirement is that the key was valid when a message was generated, if you're looking at the sender of information. For your own information, you are relying on the recipient to maintain integrity over their private (decryption) key going forward, such that the data you'd transmitted remains encrypted against all others. The first problem you point out, that any encrypted channel is not necessarily a secure channel, is valid, though given your misunderstanding on subsequent points I'm not sure how well that applies to this discussion (I still need to RTFA).

btrask 10y ago
I said trusted, not encrypted. I wasn't talking about private keys at all. I think I understand the issues involved. Thanks though.
- dredmorbius 10y ago
  And I still disagree on that point. Maybe I misunderstand (though I also think I understand teh issues involved pretty well), or maybe one or the other or both of us are communicating poorly. How would you distinguish a trusted, encrypted, and untrusted channels, say?
  - btrask 10y ago
    In the context of sharing public keys, I'd say you merely need authentication. Web of Trust being one possible mechanism. This isn't a particularly advanced topic. Relevant to my original post, information about whether the connection should be encrypted also merely needs to be authenticated, not encrypted itself. Of course, the HSTS preloading site uses HTTPS (with encryption) because it's easy and why not.
    - dredmorbius 10y ago
      Thanks. So re keysharing, authentication is a form of secure channel. I'm reading the auth and channel as independent. Auth is something of a metachannel, perhaps.
      - btrask 10y ago
        Fair enough. :)
michael_storm 10y ago
> Existing key distribution systems may or may not be encrypted, but the reason for encrypting the channel is far more to protect the interests of the requestor than the integrity of the key itself. btrask wasn't saying that encryption is necessary for key distribution; he/she was saying that HTTPS guarantees identity and integrity, both of which are necessary to trust a key. > What matters is that the web of trust associated with that key is sound (that is, you have assurance that the key belongs to whom you think it does), and that the integrity of the private key has been maintained. That's a possible alternative to btrask's proposal, though you're equating "assurance that the key belongs to whom you think it does" with "web of trust". btrask's proposal is a special case of that, in which the web of trust is simply the sender. > The first problem you point out, that any encrypted channel is not necessarily a secure channel Correct, but not what btrask said. The first problem he pointed out was the fact that clients need to know whether a host expects secure communication before ever connecting to it. > though given your misunderstanding on subsequent points I'm not sure how well that applies to this discussion That's not very nice.
- dredmorbius 10y ago
  Clarifying my own post: I'm insisting that neither a trusted or an ecrypted channel are necessary. I said that an encrypted channel could be used, and that it might not be, but that if used encryption would largely serve as a protection to the requestor, who might otherwise be subject to traffic and/or interest analysis based on the specific keys they requested, which could be presumed to be of interest, or signing keys (I'm thinking PGP protocol here) of keys of interest. Either piece of information would reduce search space for an Eve. I'm not equating trust of keys to web of trust, I'm stating that in existing (PKI/PGP) protocols, that is the assurance mechanism. And it is independent of either trust OR encryption of the key delivery channel itself. There seems to be a rather profound difficulty in distinguishing what I've said with what I've said btrask said. I'm not sure how I could be clearer, but I'm open to pointers.
  - michael_storm 10y ago
    You're both right. I only replied because you responded to points that btrask hadn't made, then claimed he/she misunderstood the topic.
nicky0 10y ago
What if someone intercepts the carrier pigeon and swaps in a different public key of their own?
- dredmorbius 10y ago
  Then the signatures don't match, or the fingerprint is wrong. If you're relying on long-term data access, messages encrypted against or signed by the true key don't match. This is an area in which PGP and SSH differ markedly. PGP is used to encrypt and authenticate data which tends to persist, SSH data used only in session. While both can use long-lived keypairs, it's the PGP keys you're more likely to notice changing (though SSH cclients tend to report this happening). Yes, that means verifying your keys, and probably through an out-of-band method.

iancarroll 10y ago

Chrome does preload public key pins for large sites, not that it's the ultimate solution to what you describe.

mintplant 10y ago
Firefox also does this.

winteriscoming 10y ago

>> If I can get you to use HTTPS when you should've used HTTP, it might be a DoS. Can you explain what you mean by this? Genuinely curious to know how it can lead to DoS?

marvy 10y ago
the only way I can think of is if the site doesn't support https
pcl 10y ago
One way would be to re-direct cacheable assets to HTTPS, thus foiling edge caching and increasing load on the origin server. In general, caching is a big problem with the naive approach to "HTTPS everywhere." A mechanism to deliver signed cacheable payloads would be great, so that static assets etc. can continue to be edge-cached.
- breatheoften 10y ago
  That seems like a good idea -- a simple scheme where the browser validates every http response from a particular domain against a key specified in that domain's SSL cert (if the appropriate field is present in the https cert) -- seems like it would work well?
  - anewhnaccount 10y ago
    This is what MEGA does. See: https://github.com/meganz/webclient/blob/master/secureboot.js https://github.com/meganz/webclient/blob/master/secureboot.j...
- continuational 10y ago
  It would still need to be encrypted, or I could tell a lot about what you're doing on the site by looking at what cacheable resources you fetch.
  - XorNot 10y ago

noja 10y ago

> Users/user agents need to know whether to expect a connection to be secure. Why not expect it to be secure? Connect to https before http.

markild 10y ago
Behavior like that needs to come with a huge warning label. It would be trivial for any man-in-the-middle to block https and server http.
- AstralStorm 10y ago
  This is exactly why browsers warn about such redirects. That said, this reminds me of a similar discussion on mail servers. There, STARTTLS sees much more use. The main problem is preventing downgrade attacks. With mail it is easy to just remember the setting for every server. Not so with websites.
  - michaelt 10y ago
    I've seen quite a bit of criticism of it for mail servers [1] because an attacker can simply block the 'STARTTLS' message and (many) clients will silently accept that. [1] https://www.agwa.name/blog/post/starttls_considered_harmful https://www.agwa.name/blog/post/starttls_considered_harmful
- hello_there 10y ago
  They could display that same "this page is not secure"-page that they display on broken certificates.
chrisseaton 10y ago
I'm not sure you can assume that the same URL with https will be the same content as at http. It could be an entirely different site that you may not have wanted.
ATsch 10y ago
what if you block the https request in some way? You can now force an Insecure connection.

belorn 10y ago

> If I can get you to use HTTP when you should've used HTTPS, I might be able to sniff your traffic That is not worst case scenario. If someone can force http, they can also inject malicious code into the stream and do anything from bank transfers to create botnets. With the worst case scenario of always https being DoS, and worst case scenario of allowing http is code injection, I would prefer deprecating http in favor of https.

derefr 10y ago
There are a few use-cases for standalone unencrypted HTTP. The two big ones: • HTTP is redundant and costly when you're already in some other tunnel: a pre-negotiated IPSec tunnel for port 80 traffic to a given peer (e.g. a load balancer to its backend); talking directly to an HTTP proxy sitting on the jump box you're VPNed or SSH tunnelled into; etc. • HTTP is actually a great wire protocol for non-networked RPC, such as between Nginx and your application server, running on the same box, over a Unix socket. FCGI, WSGI, etc. are just half-assed implementations of HTTP; you may as well just use HTTP. (Though the non-front-of-line-blocking benefits of HTTP2 RPC would be even better here, for green-threaded runtimes that can C10K.) I do agree, though, that unencrypted HTTP can likely be deprecated for web browsers. The browser-addressible web is really a pretty strictly-bounded subset of the web as a whole, and we should strive to make it safe to browse. That being said, such statements put me in mind of a future where your browser literally is not allowed to talk to all those old servers from 1997 that are still hosting whatever they were hosting back then. Instead, all requests for those "legacy" domains that nobody's updating any more would have to go to some trusted mirroring site served over HTTPS, like the Internet Archive. (The spidering logic for such "legacy mirroring" would also have to be slightly different from today's "latest mirroring" logic: if the IA's spider got MITMed to see something else, it should "doubt" the new version based on how long the previous site endured without change, and if its confidence is low enough, just continue showing people the old version.) Is that a future we want? I'm honestly not sure.

posterboy 10y ago

Hen and Egg, where do you get the secure browser from?

Tepix 10y ago
It's bundled with your OS. If you don't like the bundled one you can use it to download a different one using HTTPS.