8 ms·

The encryption of the transport and the verification of the identity of the server should be more disconnected. The CA part is only to verify that the machine

The encryption of the transport and the verification of the identity of the server should be more disconnected. The CA part is only to verify that the machine you are talking to is who it says it is.... in reality all this really verifies is that they filled out a form and there is probably a money trial somewhere leading to a real entity. But I've never understood why the identity is so tied to the transport security. It would make everyone's life easier if HTTPS could be used WITHOUT identity verification (for 90% of cases this would make the world a better place) We'd still want to purchase third-party identify verification... and browsers would still present this in the same way ("green padlocks" etc)... but even without verification every connection could be encrypted uniquely, and it would raise the bar considerably for a great number of sniffing-based issues would it not? EDIT: I guess what I'm saying is a social issue: We've put so much effort into telling everyone that "HTTPS is totally secure", that we've left no room for a system that is "Mostly secure, unless someone has compromised the remote system/network" .... maybe it's too late to teach everyone the difference between "encrypting a letter" and "verifiying that the person you give the letter to is who they say they are"

VLM 13y ago
I'm sitting here still trying to think of a way to prevent MITM attacks if you have no idea who the guy is on the other side... Maybe I need to drink more tea this early in the morning? I guess if you did something weird like flip the protocol upside down such that all people would have "internet licenses" and enter them into the browser they're using at that moment (or better yet, lets charge each user $50/yr PER BROWSER LICENSE) and it became the sites problem to encrypt to the end users key... One way or another I think you have to verify the identity of at least one side WRT MITM?
- hcarvalhoalves 13y ago
  > I'm sitting here still trying to think of a way to prevent MITM attacks if you have no idea who the guy is on the other side... Maybe I need to drink more tea this early in the morning? It's not that you don't know who the guy is, you just don't rely on a 3rd party to tell you that. See how SSH fingerprinting works.
  - ams6110 13y ago
    SSH keys work exactly like self-signed certificates. On first connection you get the "whoah, this isn't trusted, do you want to proceed" warning, and if you accept, you are not warned in the future unless the key changes. If browsers would make it easier to "permanently accept" a self-signed certificate (right now it's usually a multi-step process with blood-red warning messages at every step) we'd have the same situation as SSH keys.
    - peterwwillis 13y ago
      HTTPS involves multiple servers that are interchanged regularly and commonly use different keys. The keys change regularly. There'd be no way to know if the key changing is part of regular operation or a man in the middle.
      - bnr 13y ago
        Note that there's a difference between SSH fingerprints and (self-signed) SSL certificates. Multiple servers can easily share a certificate.
        peterwwillis 13y ago
        It would be unwise to do so. In any case, phasing out old servers and certs for new ones is common practice. Using one cert everywhere (which would mean using one set of keys everywhere, which is a horrible idea) would require more downtime for maintenance of the certificates. It's not gonna happen.
  - VLM 13y ago
    > See how SSH fingerprinting works. It doesn't, as a MITM prevention technique, for a gullible population. It doesn't even work for non-gullible population that's been trained to always hit "Y" on first connection from a host to a new server... err... I mean first connection to a MITM who then talks to the new server for you. There are ways to make the situation slightly harder like the extremely unpopular idea of putting SSH host keys in DNS and then securing DNS ... err .. probably securing DNS via a CA type backend.... Well even unsecured DNS holding SSH host keys is better than nothing, or at least it makes people more susceptible because they feel safer, or something like that.
- peeters 13y ago
  So you don't prevent MITM attacks...it's still a step up from cleartext. All this change is meant to ensure is that all HTTP/2.0 traffic is encrypted, not that it is all authenticated. For authenticated communication, we continue to have what HTTPS is today. The main issue is retraining people to not think that "https" means "safe". That's something that browsers are already good at, however, because there is already a world of difference between the user experiences of visiting a site with a trusted cert and visiting a site with an untrusted cert.
  - tptacek 13y ago
    It's not a meaningful step up from cleartext, because a passive attacker can become an active attacker with just a couple spoofed packets or control of a single DNS resolver.
    - ars 13y ago
      That's still a step up. Now you need to be an active attacker, and not just a passive one. The perfect is the enemy of the better.
      - bct 13y ago
        The worse is the enemy of the better too.
        ars 13y ago
        It's easy to decide to avoid the worse. But deciding on the tradeoff for the better vs the perfect is much harder.
        tptacek 13y ago
        This tradeoff is easy. UI that makes unauthenticated connections easier to accept is a bad idea; UI that makes certificate pinning work better is a good idea. Suggested tradeoff: pursue good idea, avoid bad idea.
- danielweber 13y ago
  The "guy on the other side" is the fridge you bought at the store and just installed in your house. You want to connect to it securely, but the fridge really has no way to prove to you who it is through any kind of third-channel. Hell, forget about fridges. It's the router you just got at Best Buy.
- jasonwatkinspdx 13y ago
  A fence doesn't stop someone with a ladder, but that doesn't mean fences are a bad idea.
gwu78 13y ago
Surely there must be a solid reason why endpoint authentication and transport encryption must be extricably combined into one program. Personally, I would find great use for the authentication function of OpenSSH as a separate program. In other words, a program that does one thing only: it verifies an endpoint is who it says it is.
breck 13y ago
I couldn't agree more. It is much more secure to visit a site with a self signed certificate than to visit the site over http. And yet, browsers start flashing red when you do that. At the least, they should show red on http, yellow on self signed https, and green on trusted https.
hsivonen 13y ago
The short answer is that at the time this stuff was designed, it was assumed that a passive attack could trivially become active instead, so it was assumed that defending against passive attacks wasn't worthwhile. Newer info about fiber splitters invalidate that assumption.
yxhuvud 13y ago
I agree. One actual use case that could be solved in a better way than today would be login portals where a user have to be logged in to access the Internet. Today, this is typically solved by issuing a redirect of some kind to the client (in the future, I guess it will receive a 511). For HTTPS, the choices are a: Dropping the packets, ensuring extra costs in the support organizations when users wonder why their internet doesn't work. b: Doing a MITM and issue a redirect to the login portal that way. Different operators choose different solutions here. Neither choice is good. Having a way of telling the client, that yes, while the connection is still encrypted, it didn't end up at the place it expected. Might it be possible to add to TLS so that there are some way of issuing gateway redirect? Perhaps, perhaps not. I've seen precious little action in that area.

VLM 13y ago

I'm sitting here still trying to think of a way to prevent MITM attacks if you have no idea who the guy is on the other side... Maybe I need to drink more tea this early in the morning? I guess if you did something weird like flip the protocol upside down such that all people would have "internet licenses" and enter them into the browser they're using at that moment (or better yet, lets charge each user $50/yr PER BROWSER LICENSE) and it became the sites problem to encrypt to the end users key... One way or another I think you have to verify the identity of at least one side WRT MITM?

hcarvalhoalves 13y ago
> I'm sitting here still trying to think of a way to prevent MITM attacks if you have no idea who the guy is on the other side... Maybe I need to drink more tea this early in the morning? It's not that you don't know who the guy is, you just don't rely on a 3rd party to tell you that. See how SSH fingerprinting works.
- ams6110 13y ago
  SSH keys work exactly like self-signed certificates. On first connection you get the "whoah, this isn't trusted, do you want to proceed" warning, and if you accept, you are not warned in the future unless the key changes. If browsers would make it easier to "permanently accept" a self-signed certificate (right now it's usually a multi-step process with blood-red warning messages at every step) we'd have the same situation as SSH keys.
  - peterwwillis 13y ago
    HTTPS involves multiple servers that are interchanged regularly and commonly use different keys. The keys change regularly. There'd be no way to know if the key changing is part of regular operation or a man in the middle.
    - bnr 13y ago
      Note that there's a difference between SSH fingerprints and (self-signed) SSL certificates. Multiple servers can easily share a certificate.
      - peterwwillis 13y ago
        It would be unwise to do so. In any case, phasing out old servers and certs for new ones is common practice. Using one cert everywhere (which would mean using one set of keys everywhere, which is a horrible idea) would require more downtime for maintenance of the certificates. It's not gonna happen.
- VLM 13y ago
  > See how SSH fingerprinting works. It doesn't, as a MITM prevention technique, for a gullible population. It doesn't even work for non-gullible population that's been trained to always hit "Y" on first connection from a host to a new server... err... I mean first connection to a MITM who then talks to the new server for you. There are ways to make the situation slightly harder like the extremely unpopular idea of putting SSH host keys in DNS and then securing DNS ... err .. probably securing DNS via a CA type backend.... Well even unsecured DNS holding SSH host keys is better than nothing, or at least it makes people more susceptible because they feel safer, or something like that.
peeters 13y ago
So you don't prevent MITM attacks...it's still a step up from cleartext. All this change is meant to ensure is that all HTTP/2.0 traffic is encrypted, not that it is all authenticated. For authenticated communication, we continue to have what HTTPS is today. The main issue is retraining people to not think that "https" means "safe". That's something that browsers are already good at, however, because there is already a world of difference between the user experiences of visiting a site with a trusted cert and visiting a site with an untrusted cert.
- tptacek 13y ago
  It's not a meaningful step up from cleartext, because a passive attacker can become an active attacker with just a couple spoofed packets or control of a single DNS resolver.
  - ars 13y ago
    That's still a step up. Now you need to be an active attacker, and not just a passive one. The perfect is the enemy of the better.
    - bct 13y ago
      The worse is the enemy of the better too.
      - ars 13y ago
        It's easy to decide to avoid the worse. But deciding on the tradeoff for the better vs the perfect is much harder.
        tptacek 13y ago
        This tradeoff is easy. UI that makes unauthenticated connections easier to accept is a bad idea; UI that makes certificate pinning work better is a good idea. Suggested tradeoff: pursue good idea, avoid bad idea.
danielweber 13y ago
The "guy on the other side" is the fridge you bought at the store and just installed in your house. You want to connect to it securely, but the fridge really has no way to prove to you who it is through any kind of third-channel. Hell, forget about fridges. It's the router you just got at Best Buy.
jasonwatkinspdx 13y ago
A fence doesn't stop someone with a ladder, but that doesn't mean fences are a bad idea.

gwu78 13y ago

Surely there must be a solid reason why endpoint authentication and transport encryption must be extricably combined into one program. Personally, I would find great use for the authentication function of OpenSSH as a separate program. In other words, a program that does one thing only: it verifies an endpoint is who it says it is.

breck 13y ago

I couldn't agree more. It is much more secure to visit a site with a self signed certificate than to visit the site over http. And yet, browsers start flashing red when you do that. At the least, they should show red on http, yellow on self signed https, and green on trusted https.

hsivonen 13y ago

The short answer is that at the time this stuff was designed, it was assumed that a passive attack could trivially become active instead, so it was assumed that defending against passive attacks wasn't worthwhile. Newer info about fiber splitters invalidate that assumption.

yxhuvud 13y ago

I agree. One actual use case that could be solved in a better way than today would be login portals where a user have to be logged in to access the Internet. Today, this is typically solved by issuing a redirect of some kind to the client (in the future, I guess it will receive a 511). For HTTPS, the choices are a: Dropping the packets, ensuring extra costs in the support organizations when users wonder why their internet doesn't work. b: Doing a MITM and issue a redirect to the login portal that way. Different operators choose different solutions here. Neither choice is good. Having a way of telling the client, that yes, while the connection is still encrypted, it didn't end up at the place it expected. Might it be possible to add to TLS so that there are some way of issuing gateway redirect? Perhaps, perhaps not. I've seen precious little action in that area.