Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Every Byte of a TLS Connection Explained and Reproduced

tls.ulfheim.net

Post reply on HN
Print view View original

31–40 of 104 posts

Re: Every Byte of a TLS Connection Explained and Reproduced

#31

Post by tialaramex »

thejoeflow wrote: post #15

Kind of ironic that their website is using an invalid security certificate?

The site is currently presenting a Let's Encrypt certificate issued just under 24 hours ago. There have historically always (for reasonable definitions of always) been valid certs for this site, although of course I can't tell from here that they were always properly installed.

Likely explanations for your experience:

1. Your clock is wrong. If your system currently thinks this is Thursday 11 October for example, that's a problem, 'cos this is Friday 12 October.

2. There's some subtle configuration error on their server (seems unlikely as it looks to be just a generic AWS setup) that results in the wrong certificate being presented.

3. Your OS or browser trust store lacks the root CA "DST Root CA X3" operated by IdenTrust. If you didn't deliberately choose to do this, you should investigate as most likely you aren't getting important security updates.

All three causes can often by diagnosed by closely examining the detailed error reported in a browser e.g. SEC_ERROR_EXPIRED_CERTIFICATE

Re: Every Byte of a TLS Connection Explained and Reproduced

#32

Post by logicallee »

nebulous1 wrote: post #14
logicallee wrote: post #9

Earlier quoted context omitted.

Unrelated but: based on your understanding of establishing a TLS session with a server, and then traffic through that connection, do you think the new Gmail user interface for the web (desktop) is sufficiently speedy? The reason I ask in this thread is that this thread treats some of the low-level minimum traffic necessary between clients and servers.

Sufficiently speedy for what? It's not clear what you're asking. Gmail obviously runs over TLS. It also seem pretty nippy to me, but TLS only has a minor impact on the speed.

>It also seem pretty nippy to me

OK. (my experience since the redesign is the opposite.)

Re: Every Byte of a TLS Connection Explained and Reproduced

#33

Post by randlet »

syncsynchalt wrote: post #19

Author here - I was going to publish this today but it leaked out ahead of time. Enjoy! EDIT: I'm putting a CDN in place.

Thanks! This is really a fantastic resource. Something like a TLS connection is one of those things that seems really intimidating but when you see it laid out like this it makes you feel like 'I can understand this!'. Great work.

Re: Every Byte of a TLS Connection Explained and Reproduced

#34

Post by gear54rus »

deaps wrote: post #30
sgwae wrote: post #4

Earlier quoted context omitted.

This is what happens under the hood of every ping request.

A ping is very much different. A ping is (typically) simply an ICMP Echo Request, (not TCP, thus no TLS, etc). The receiving device, if accepting echo requests and configured to reply with echo replies, then responds with an ICMP Echo Reply - or some device in the middle (or the device itself could respond with an ICMP unreachable, or some other response - or quite simply drop the ICMP Echo Request entirely and silen…

If I'm not mistaken, its not UDP, it's ICMP, like you said

Re: Every Byte of a TLS Connection Explained and Reproduced

#35

Post by syncsynchalt »

toast0 wrote: post #22

This is wonderful! I may make a version where the bytes used for lengths are highlighted, since it feels like so many bytes are lengths; look at the SNI extension, which has three 16-bit lengths, I know why they're there, but SNI probably shouldn't be a list, and even if it was a list, an extension that consists solely of a list has a list of the length of the extension, you shouldn't need two bytes for that, and if…

Agreed, and I think some pain must have gone into those redundant length bytes. The way they've done it makes it very easy and natural to extend any part of any record later, but it gets ridiculous when you have to document them.

Re: Every Byte of a TLS Connection Explained and Reproduced

#37

Post by syncsynchalt »

kalimatas wrote: post #29

The irony is: I get "Your connection is not secure" when trying to open the link.

I've uncapped MaxRequestWorkers while I wait for the Cloudflare queue, it should work now (I believe you were seeing an error related to TLS timeout).

Re: Every Byte of a TLS Connection Explained and Reproduced

#38

Post by bebop »

syncsynchalt wrote: post #19

Author here - I was going to publish this today but it leaked out ahead of time. Enjoy! EDIT: I'm putting a CDN in place.

Great illustration, I am going to share this with the rest of my team. One thing that I would find interesting is how x509 client certificates fit into the negotiation. I know this is optional so I don't know how it would fit into your flow easily though.

Re: Every Byte of a TLS Connection Explained and Reproduced

#39

Post by tialaramex »

pimlottc wrote: post #25
bungie4 wrote: post #12

Beautiful. I recently had to implement two way auth over 1.2 and this would have saved much hair pulling. (and who does TWO way auth over an MPLS connection. Turns out, us).

I feel your pain. Two-way TLS is a funny thing, it's supported by the standards and even most implementations but its actual use is minuscule compared to "normal" one-way TLS, so much so that it's hard to find documentation even acknowledging two-way TLS exists, let alone how to use it. And don't get me started about the hassles of obtaining signed certificates that are actually usable for client auth...

> And don't get me started about the hassles of obtaining signed certificates that are actually usable for client auth...

What sort of clients were you authenticating? The Web PKI needs to be trusted by random people from the whole world, but most mutually authenticated systems have a relatively small number of clients which are known to the server operator out-of-band. So probably the Web PKI is not the right choice. Instead you (the server operator or some neutral facilitator if it's a group of providers operating services for the same clients) should operate a CA for this purpose, not piggyback on the Web PKI.

One reason not to use the Web PKI if you aren't actually part of the public Internet is that we, to put it bluntly, don't give a shit about people who do that. Running a PKI is expensive (not just in dollar terms, it needs a bunch of smart, motivated people who are morally upright or it's worthless), and this one is ours, so it obeys our rules.

If you have your own PKI (or just one CA) you set the rules. Fifty year certificates for 1024-bit RSA? Why not. A current passport photograph baked into every certificate? Sure. Want the issuer to mint the keys and keep a copy? Do as you please. All those things are prohibited in the Web PKI.

Re: Every Byte of a TLS Connection Explained and Reproduced

#40

Post by taftster »

pimlottc wrote: post #25
bungie4 wrote: post #12

Beautiful. I recently had to implement two way auth over 1.2 and this would have saved much hair pulling. (and who does TWO way auth over an MPLS connection. Turns out, us).

I feel your pain. Two-way TLS is a funny thing, it's supported by the standards and even most implementations but its actual use is minuscule compared to "normal" one-way TLS, so much so that it's hard to find documentation even acknowledging two-way TLS exists, let alone how to use it. And don't get me started about the hassles of obtaining signed certificates that are actually usable for client auth...

Most two-way implementations are generally privately controlled. You can act as your own certification authority and sign both the client and server certificates for a private communication.

Totally curious, it sounds like you were going for a traditionally signed certificate approach. So you had clients that you didn't "own" -- normal Joe Public -- using your service? If so, that is definitely way outside the norm. If not, why didn't you just sign your own certs?

Post reply on HN