5 ms·

Please note that this is from 2009 and a lot of things have changed. If you read it consider it a history lesson of how TLS was in 2009, not how it is today.

by hannob 6y ago

javajosh 6y ago
It would be useful if you were to list at least some of the things that have changed.
- shawabawa3 6y ago
  I guess they're referring to http/2, http/3 and quic?
- hannob 6y ago
  The most obvious thing being that it describes primarily RSA-handshake and RC4 encryption. For good reasons these aren't used any more. But there's plenty of tiny details that are obsolete as well, e.g. it describes the timestamp which is no longer used and usually filled with random data these days.
  - londons_explore 6y ago
    It's a shame the clients timestamp is no longer sent to the server. If it was, a server could compensate for a client clock being wrong by many decades by providing an old expired certificate.
    - spockz 6y ago
      If this was the behaviour of an app up to 2009 you could at least serve certificates to those apps still.
    - forgotmypw17 6y ago
      This is one of the reasons I still use http primarily and do not promote https. There are many barriers to an https connection, and this is one of them. Another is the version race, meaning browsers as recent as 2012 are no longer compatible with today's https sites.
      - Shared404 6y ago
        While I understand where you are coming from, and in fact use http on my personal site, I have to disagree about which is better. For the Web (Meaning HTTP/S), compatibility back past 5-6 years seems kind of pointless. There's to much changing to fast at too many layers to be a really good target, unless you are serving an actually static site (Which is not a bad thing, it's what I do). Even then, HTTPS still has value, as it can prevent ISP's from injecting advertisements. I don't believe this is currently a large issue in the US, but I remember a recent discussion about bad behaviour by ISP's in India and other countries. Edit: I do however believe that (for a static site on https) it is a good idea to allow a fall back to http, assuming of course that you are fine with the contents being mitm'd. Also, I think the Gopher is a good thing to serve in this kind of situation.
    - vbezhenar 6y ago
      Why client does not accept certificate from the future? What attack is supposed to be prevented?
      - toast0 6y ago
        X.509 cerrificates have a not before and a not after date, so validators check them. It's a real pain when you have to let a certificate sit for a day to compensate for clients with poorly set clocks or poorly written date comparisons.
        tialaramex 6y ago
        Google's experiments suggest that the vast majority of clients are off by an hour (incorrect "daylight saving" adjustments / next door's timezone) or less. They did do work on having clients with Internet access just bootstrap a roughly correct time from first principles, but I don't know if Chrome/ Android do this out of the box. Public Issuers generally backdate certificates by a small amount of time to allow for that one hour. This is permitted (unlike backdating to avoid other rules) by the Baseline Requirements, so you should find you don't need to wait before using the certificates you are issued.
        toast0 6y ago
        > so you should find you don't need to wait before using the certificates you are issued. Thanks, but no. I had to wait about 12 hours to deploy replacement certificates after Heartbleed, in order to balance cert errors with loss of privacy. A large number of the clients I had to support interpret the dates as local time, which isn't helpful when they're in the western hemisphere and GoDaddy wouldn't backdate certs at all. Last I had a cert issued, DigiCert set not before to the order time even for re-issues or duplicates, so that was a lot easier to manage.
        a1369209993 6y ago
        This is true, but doesn't actually answer the question of what attack respecting the not-before date is supposed to prevent.
- tialaramex 6y ago
  For TLS 1.3 (a large fraction but not majority of today's HTTPS servers) let's go step-by-step like the article: Random: Now all 32 bytes are random Session ID: This will now all be random if we've never talked to this server before or if we believe it speaks TLS 1.3 Cipher suites: There are newer suites [with much shorter names] for TLS 1.3 because some parameters are now fixed. SNI: This is still there (work on Encrypted SNI which became Encrypted Client Hello is ongoing) NEW Supported versions: Compliant servers pick the newest version they recognise from a list the client provides. NEW Key share: A TLS 1.3 client proposes one or more (Elliptic curve) Diffie Hellman key agreements. Most servers will accept one of them. OK, on to the Server Hello... Random: Again all 32 bytes are random unless the server speaks TLS 1.3 (or newer) and has the impression at this point that the client does not. In this case the server overwrites a few of the bytes with the ASCII "DOWNGRD" (downgrade). A TLS 1.2 (or older) client sees no significance in this, but a TLS 1.3 client is alerted that somebody is meddling, because it's extremely unlikely that a server randomly spells "DOWNGRD" and also only knows an older protocol version. Also, as a special case TLS 1.3 servers scribble over the entire random byte sequence with SHA256("HelloRetryRequest") if they wish you to try TLS 1.3 hello again with a different key share because all your proposals were unsuitable. Session ID: The random nonsense from the client is echo'd back in TLS 1.3 Cipher suite: Still whichever suite the server picked. NEW Supported versions: TLS 1.3 or better servers will echo back versions they support. NEW Key share: Assuming the Client's proposed key shares are acceptable in TLS 1.3 the server answers with a share of their own here and then... In TLS 1.3 and newer everything else is encrypted. Client and server have performed DH key agreement, so now they both know a random secret which they will use to begin encrypting any subsequent messages. Certificate: is an example of something that's now encrypted. Also in TLS 1.3 the specification follows real world practice that this isn't necessarily a "chain" just one leaf certificate plus any other certificates that might help the client reach a trust decision. The TLS 1.3 protocol is a relatively nice shape in its natural form, but what you see on the wire is spelled very weirdly because this is the only way for it to pass various rusty middleboxes and not blow up poorly implemented legacy servers out there in the real world.
  - javajosh 6y ago
    Awesome, thank you. This is one of those HN comments that go in my notes beside the original article.
commandlinefan 6y ago
I missed that at first and when I scrolled down and saw TLS 1.0 I thought, "Wait, Amazon is using WHAT?"

Please note that this is from 2009 and a lot of things have changed. If you read it consider it a history lesson of how TLS was in 2009, not how it is today.

by hannob 6y ago

Please note that this is from 2009 and a lot of things have changed. If you read it consider it a history lesson of how TLS was in 2009, not how it is today.

javajosh 6y ago

It would be useful if you were to list at least some of the things that have changed.

shawabawa3 6y ago
I guess they're referring to http/2, http/3 and quic?
hannob 6y ago
The most obvious thing being that it describes primarily RSA-handshake and RC4 encryption. For good reasons these aren't used any more. But there's plenty of tiny details that are obsolete as well, e.g. it describes the timestamp which is no longer used and usually filled with random data these days.
- londons_explore 6y ago
  It's a shame the clients timestamp is no longer sent to the server. If it was, a server could compensate for a client clock being wrong by many decades by providing an old expired certificate.
  - spockz 6y ago
    If this was the behaviour of an app up to 2009 you could at least serve certificates to those apps still.
  - forgotmypw17 6y ago
    This is one of the reasons I still use http primarily and do not promote https. There are many barriers to an https connection, and this is one of them. Another is the version race, meaning browsers as recent as 2012 are no longer compatible with today's https sites.
    - Shared404 6y ago
      While I understand where you are coming from, and in fact use http on my personal site, I have to disagree about which is better. For the Web (Meaning HTTP/S), compatibility back past 5-6 years seems kind of pointless. There's to much changing to fast at too many layers to be a really good target, unless you are serving an actually static site (Which is not a bad thing, it's what I do). Even then, HTTPS still has value, as it can prevent ISP's from injecting advertisements. I don't believe this is currently a large issue in the US, but I remember a recent discussion about bad behaviour by ISP's in India and other countries. Edit: I do however believe that (for a static site on https) it is a good idea to allow a fall back to http, assuming of course that you are fine with the contents being mitm'd. Also, I think the Gopher is a good thing to serve in this kind of situation.
  - vbezhenar 6y ago
    Why client does not accept certificate from the future? What attack is supposed to be prevented?
    - toast0 6y ago
      X.509 cerrificates have a not before and a not after date, so validators check them. It's a real pain when you have to let a certificate sit for a day to compensate for clients with poorly set clocks or poorly written date comparisons.
      - tialaramex 6y ago
        Google's experiments suggest that the vast majority of clients are off by an hour (incorrect "daylight saving" adjustments / next door's timezone) or less. They did do work on having clients with Internet access just bootstrap a roughly correct time from first principles, but I don't know if Chrome/ Android do this out of the box. Public Issuers generally backdate certificates by a small amount of time to allow for that one hour. This is permitted (unlike backdating to avoid other rules) by the Baseline Requirements, so you should find you don't need to wait before using the certificates you are issued.
        toast0 6y ago
        > so you should find you don't need to wait before using the certificates you are issued. Thanks, but no. I had to wait about 12 hours to deploy replacement certificates after Heartbleed, in order to balance cert errors with loss of privacy. A large number of the clients I had to support interpret the dates as local time, which isn't helpful when they're in the western hemisphere and GoDaddy wouldn't backdate certs at all. Last I had a cert issued, DigiCert set not before to the order time even for re-issues or duplicates, so that was a lot easier to manage.
      - a1369209993 6y ago
        This is true, but doesn't actually answer the question of what attack respecting the not-before date is supposed to prevent.
tialaramex 6y ago
For TLS 1.3 (a large fraction but not majority of today's HTTPS servers) let's go step-by-step like the article: Random: Now all 32 bytes are random Session ID: This will now all be random if we've never talked to this server before or if we believe it speaks TLS 1.3 Cipher suites: There are newer suites [with much shorter names] for TLS 1.3 because some parameters are now fixed. SNI: This is still there (work on Encrypted SNI which became Encrypted Client Hello is ongoing) NEW Supported versions: Compliant servers pick the newest version they recognise from a list the client provides. NEW Key share: A TLS 1.3 client proposes one or more (Elliptic curve) Diffie Hellman key agreements. Most servers will accept one of them. OK, on to the Server Hello... Random: Again all 32 bytes are random unless the server speaks TLS 1.3 (or newer) and has the impression at this point that the client does not. In this case the server overwrites a few of the bytes with the ASCII "DOWNGRD" (downgrade). A TLS 1.2 (or older) client sees no significance in this, but a TLS 1.3 client is alerted that somebody is meddling, because it's extremely unlikely that a server randomly spells "DOWNGRD" and also only knows an older protocol version. Also, as a special case TLS 1.3 servers scribble over the entire random byte sequence with SHA256("HelloRetryRequest") if they wish you to try TLS 1.3 hello again with a different key share because all your proposals were unsuitable. Session ID: The random nonsense from the client is echo'd back in TLS 1.3 Cipher suite: Still whichever suite the server picked. NEW Supported versions: TLS 1.3 or better servers will echo back versions they support. NEW Key share: Assuming the Client's proposed key shares are acceptable in TLS 1.3 the server answers with a share of their own here and then... In TLS 1.3 and newer everything else is encrypted. Client and server have performed DH key agreement, so now they both know a random secret which they will use to begin encrypting any subsequent messages. Certificate: is an example of something that's now encrypted. Also in TLS 1.3 the specification follows real world practice that this isn't necessarily a "chain" just one leaf certificate plus any other certificates that might help the client reach a trust decision. The TLS 1.3 protocol is a relatively nice shape in its natural form, but what you see on the wire is spelled very weirdly because this is the only way for it to pass various rusty middleboxes and not blow up poorly implemented legacy servers out there in the real world.
- javajosh 6y ago
  Awesome, thank you. This is one of those HN comments that go in my notes beside the original article.

commandlinefan 6y ago

I missed that at first and when I scrolled down and saw TLS 1.0 I thought, "Wait, Amazon is using WHAT?"