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

61–70 of 104 posts

Re: Every Byte of a TLS Connection Explained and Reproduced

#61

Post by syncsynchalt »

nanidin wrote: post #59

tls.ulfheim.net - "This site is blocked due to a security threat." ulfheim.net - no problem At least according to my megacorp threat filter. I have never actually seen something blocked before, and it's a shame because the page would be great to share with my team.

Wonder why that would be, tls.ulfheim.net is a CNAME to ulfheim.net, they're just different apache vhosts. Same cert (using SAN).

The only things I can think of:

  - it doesn't like the hostname (tls?)
  - the hostname is new, and has no reputation
  - too much h4cking content

Re: Every Byte of a TLS Connection Explained and Reproduced

#62

Post by syncsynchalt »

syncsynchalt wrote: post #20
kodablah wrote: post #18

There's a lot of practicality I learned from reading the Go source and implementing my own (e.g. always an array of a single value of 0 for compression method). Now do a version with DTLS (one more message type, couple more fields on existing types, and logic concerning retries). Also, now do a TLS 1.3 one.

Yep, reading the Go source is what inspired me to do this, it's still very compact and readable. I originally used an AEAD cipher but found it was impossible to demonstrate on the command line (openssl enc refuses to do AEAD because it can't confirm the authentication in a streaming context). A friend asked me to demonstrate ALPN in this but as I looked into it I found it was distracting, as there's already so much g…

Link to the go source: https://golang.org/src/crypto/tls/

Re: Every Byte of a TLS Connection Explained and Reproduced

#63

Post by richardwhiuk »

tialaramex wrote: post #39
pimlottc wrote: post #25

Earlier quoted context omitted.

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…

Ignoring the Web PKI defaults though is probably a silly idea - e.g. long lived certificates with rubbish hash algorithms, huge certificates, and issuer kept keys are all really bad ideas, in almost any scenario.

Re: Every Byte of a TLS Connection Explained and Reproduced

#64

Post by logicallee »

pjc50 wrote: post #53
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.

Gmail was using TLS since day 1. If it's slow for you the first likely culprit is the sheer weight of Javascript and DOM work, followed by making more web requests than necessary.

>the sheer weight of Javascript and DOM work, followed by making more web requests than necessary.

can you (or anyone) put this into quantitative terms? How much are we talking about here? I realize this is a bit off-topic, but the topic is "every byte explained", so I think the people who are interested are in the right place to discuss it.

Re: Every Byte of a TLS Connection Explained and Reproduced

#66

Post by Obi_Juan_Kenobi »

logicallee wrote: post #64
pjc50 wrote: post #53

Earlier quoted context omitted.

Gmail was using TLS since day 1. If it's slow for you the first likely culprit is the sheer weight of Javascript and DOM work, followed by making more web requests than necessary.

>the sheer weight of Javascript and DOM work, followed by making more web requests than necessary. can you (or anyone) put this into quantitative terms? How much are we talking about here? I realize this is a bit off-topic, but the topic is "every byte explained", so I think the people who are interested are in the right place to discuss it.

You can see a lot of what's going on with a e.g. DevTools in Chrome. Right click -> inspect

You'll want to go to the performance tab, and then record and reload the page (ctrl-shift-e). For me, about 3/4ths of the time is spent 'scripting' which is 'JS and DOM work'.

It's not terribly enlightening, though, because all the JS is minified and takes some work to understand.

Re: Every Byte of a TLS Connection Explained and Reproduced

#67

Post by munchbunny »

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...

For client auth, assuming you control the server, would it be easier to just issue your own and install the root on the server?

Re: Every Byte of a TLS Connection Explained and Reproduced

#70

Post by logicallee »

Obi_Juan_Kenobi wrote: post #66
logicallee wrote: post #64

Earlier quoted context omitted.

>the sheer weight of Javascript and DOM work, followed by making more web requests than necessary. can you (or anyone) put this into quantitative terms? How much are we talking about here? I realize this is a bit off-topic, but the topic is "every byte explained", so I think the people who are interested are in the right place to discuss it.

You can see a lot of what's going on with a e.g. DevTools in Chrome. Right click -> inspect You'll want to go to the performance tab, and then record and reload the page (ctrl-shift-e). For me, about 3/4ths of the time is spent 'scripting' which is 'JS and DOM work'. It's not terribly enlightening, though, because all the JS is minified and takes some work to understand.

how much time is that for you? How does it compare to another dynamic site such as the one we're on (HN) when you're logged in?
Post reply on HN