[HN Gopher] TLS Mastery
       ___________________________________________________________________
        
       TLS Mastery
        
       Author : rodrigo975
       Score  : 134 points
       Date   : 2021-04-10 08:54 UTC (1 days ago)
        
 (HTM) web link (mwl.io)
 (TXT) w3m dump (mwl.io)
        
       | friend-monoid wrote:
       | I bought it and skimmed through most of it, and I have a hard
       | time recommending it personally. It's really short on the crypto
       | and offers no insight into why TLS behaves the way it does. I
       | would like to at least see an explanation of the TLS handshake
       | process, but there is none. It's a lot of "using openssl
       | s_client"-type of discussion; i.e. how to use it, not so much on
       | how it works, and that applies to most of the book (including the
       | ocsp parts).
       | 
       | Practical, not necessarily theoretical; but if that's what you
       | are looking for, then it's a great book.
        
         | devy wrote:
         | > It's really short on the crypto and offers no insight into
         | why TLS behaves the way it does. ... It's a lot of "using
         | openssl s_client"-type of discussion;
         | 
         | That is literally how the author explained in his book's Amazon
         | Kindle version's free preview[1]. The author specifically said
         | he is not a brilliant mathematician so he's not going into the
         | details of explaining the math but rather explain the how-to
         | from a practitioner's standpoint. Obviously, you don't need to
         | be a brilliant mathematician in order to under the math behind
         | public-key cryptography but for many engineers, I agree with
         | the author that I care more of about how to configure it and
         | make it work securely rather than the reason behind the scene.
         | The author also claimed that he would recommend some further
         | readings if you would like to dig into it more.
         | 
         | [1]: https://www.amazon.com/gp/product/B091TBX4WH
        
       | ancarda wrote:
       | Anyone know if the book covers ESNI? Or if there's a good
       | resource on how to set that up with Nginx, CloudFlare DNS, and
       | Let's Encrypt?
       | 
       | EDIT: Okay, it looks like this is not yet ready for most people
       | to use.
        
         | 1vuio0pswjnm7 wrote:
         | https://defo.ie
         | 
         | As an end user, I have been using ESNI-enabled openssl to make
         | HTTP requests to sites using Cloudflare and for me it works
         | great.
        
         | tialaramex wrote:
         | Encrypted Client Hello, which is what eSNI developed into, is
         | an active draft for the TLS working group. If you have relevant
         | expertise I'm sure that the group would be happy to have you,
         | in particular if you have any insight into how to achieve goals
         | like _Don 't Stand Out_ while also keeping ECH as simple as
         | possible.
         | 
         | https://www.youtube.com/watch?v=AIDnO_QB64A is the most recent
         | interim video conference meeting on this topic.
         | 
         | I expect that during 2021 they'll pin down the more
         | controversial parts that remain to be done.
        
       | srathi wrote:
       | I recommend this blog post as a good primer for TLS.
       | 
       | http://www.moserware.com/2009/06/first-few-milliseconds-of-h...
        
       | superkuh wrote:
       | Step 1. Give up volition to a third party certificate authority
       | and hope your internet service is never controversial enough to
       | get it revoked like sci-hub.
        
         | iso1631 wrote:
         | I have my own certs signed by my own CA that I trust enough to
         | have in my browser allowed CA cache
         | 
         | However I'd far rather be able to import a root cert with my
         | own constraints -- use this root cert to authenticate by only
         | for sites in my list (which I'd add say
         | _.blarge.com,_.muhhaa.de, dohicky.google.com, etc), but that
         | feature doesn 't site in firefox, I either trust the root or I
         | don't, which means I have to be far more careful about the root
         | cert because rather than intercepting a few dev sites.
        
           | tedunangst wrote:
           | Firefox supports the name constraints extension.
        
           | tialaramex wrote:
           | _If_ you want this, (I don 't advise it but you seem to have
           | your heart set) the way to do it goes like this:
           | 
           | 1. Generate a fresh root as you do today. Keep the resulting
           | CA certificate for the root to one side, let's call this CA1
           | 
           | 2. Create an intermediate CA certificate, this says there's a
           | new CA, let's call it CA2 with a new private key, and _this_
           | certificate gets to have constraints. Put all the constraints
           | you 've decided upon in here. Sign it using CA1 with your
           | private key.
           | 
           | 3. Destroy the private key for CA1.
           | 
           | 4. Tell Firefox to trust root CA1.
           | 
           | 5. You can now issue from CA2 and since it chains back to CA1
           | this is trustworthy, but only so long as it obeys the
           | constraints. You can't issue from CA1 (which is fully
           | trusted) because you destroyed the key.
        
       | baybal2 wrote:
       | I learned few years ago that you can do TLS auth without client
       | side certs.
       | 
       | People were always surprised how they stay logged in after
       | clearing cookies.
        
         | BiteCode_dev wrote:
         | Do you have a link to a tutotial for that ?
        
           | baybal2 wrote:
           | No, but it's very easy to grasp.
           | https://blog.cloudflare.com/tls-session-resumption-full-
           | spee... did it perfectly.
           | 
           | Basically, you need to get the session ticket from the
           | webserver being available at the backend, and set its
           | lifetime to something reasonable.
           | 
           | At least NGINX can then handle all of the session
           | resume/renew logic by itself.
        
         | ivanr wrote:
         | What you're describing can be achieved by misusing TLS session
         | IDs, but the technique doesn't work reliably and it's not
         | secure.
         | 
         | In essence, when client and server handshake, a unique session
         | ID is generated. The server can associate this ID with a user
         | account and use it to identify the user on subsequent requests.
         | Except this works only when client and server are connected
         | directly. If there is a CDN in front of the server, or a proxy
         | in front of the client, the session ID will refer to the
         | intermediary devices, which may be used among many users, and
         | so on. In addition, clients can (and often do) throw away TLS
         | sessions very frequently. The last time I tried this technique
         | (admittedly some two decades ago) Internet Explorer was
         | rotating the session ID every 5 minutes.
         | 
         | There is something called Channel Binding (or Token Binding,
         | the names have changed a couple of times) that can be used to
         | create a cryptographic identity at TLS level. It's the same
         | idea as session ID binding, just properly secure. Google spent
         | a lot of time experimenting with it but IIRC ultimately decided
         | against it. Here's a link to the slides from a couple of years
         | ago:
         | https://tools.ietf.org/agenda/90/slides/slides-90-uta-0.pdf
         | 
         | There is also in TLS something called pre-shared key (PSK)
         | authentication, which is a way to handshake without
         | certificates, but client and server have to share a password
         | instead. (In TLS 1.3, the PSK mechanism is also used for
         | session resumption.)
        
           | baybal2 wrote:
           | FYI CloudFlare uses it massively, and has, CDN-wide as I
           | believe, session cookie resume.
        
           | tialaramex wrote:
           | > There is also in TLS something called pre-shared key (PSK)
           | authentication, which is a way to handshake without
           | certificates, but client and server have to share a password
           | instead.
           | 
           | It is _imperative_ to understand that passwords are not
           | suitable for a TLS 1.3 PSK.
           | 
           | I even ran into this with some people working on CMP in LAMPS
           | ("Limited Additional Mechanisms for PKIX and S/MIME" the poor
           | group left with the work that couldn't be avoided entirely to
           | fix problems in PKIX and/or S/MIME)
           | 
           | No, you can't just run the password through PBKDF2 and
           | consider that good enough. If you _really_ need password
           | authentication, you need an actual password based
           | authentication mechanism, do not try to jury rig PSKs.
        
         | luto wrote:
         | Which TLS feature are you referring to?
        
           | spockz wrote:
           | I think he might be referring to tls sessions. When a client
           | comes back to a server it remembers that it connected to it
           | can send a session Id encrypted with the master secret or a
           | complete session ticket. When the handshake completes
           | successfully you know who it was if you stored that
           | information. It saves using a cookie. Also it might not be
           | supported in every client.
           | 
           | I think you still need to have mTLS or another credential to
           | use initially for auth. Unless I miss an option. As such I
           | don't see much value over mtls in a corporate network
           | setting.
        
             | ALOHa100 wrote:
             | https://blog.cloudflare.com/tls-session-resumption-full-
             | spee...
        
       | Voline wrote:
       | In my opinion, Michael W Lucas is one of the best tech writers
       | working today. I have made great use of his books Absolute
       | OpenBSD, SSH Mastery, and Httpd & Relayd Mastery.
       | 
       | He also wrote Absolute FreeBSD and PGP & GPG: Email for the
       | Practical Paranoid, among many others.
        
       | rcgorton wrote:
       | "Mastery" as described seems to be how to use your browser or app
       | to perform this, without actually understanding it. It is not
       | necessary to understand in detail the crypto underpinnings - that
       | is WAAAY beyond most folks (myself included) But if you need to
       | understand the TLS actions, including HTTP2 details, this is NOT
       | useful.
        
       | smitty1e wrote:
       | Feisty Duck has some great material and training in this vein =>
       | https://www.feistyduck.com/
       | 
       | I just sat through the 4 1/2 day online training they offer, and
       | thought it was worth the price, as long as the company was
       | picking up the tab.
        
       | calpaterson wrote:
       | Can someone who has read it post their review?
       | 
       | The contents look good and I feel like it might help me patch
       | some holes in my knowledge. It has the advantage of at least
       | looking like it's up to date (a lot of SSL writing has been
       | obsoleted).
        
         | FlacoJones wrote:
         | Just bought the Tux edition on Amazon for Kindle. $10. Says it
         | was published/updated April 5, 2021. Hands on practice with
         | OpenSSL. Engaging writing style. Doesn't assume too much or too
         | little. No bullshit.
         | 
         | This command alone in the first ten pages makes it worth it.
         | Establish TLS connection, get certs, and decode certs for any
         | site:
         | 
         | openssl s_client -showcerts -connect www.mwl.io:443 </dev/null
         | | openssl x509 -text -noout
         | 
         | 10/10.
        
           | whydoyoucare wrote:
           | Hmmm... for that kind of stuff, I've found sslshopper's page
           | to be very useful. https://www.sslshopper.com/article-most-
           | common-openssl-comma...
           | 
           | And for the TLS handshake, this is incredibly useful:
           | https://tls.ulfheim.net (The Illustrated TLS Connection).
           | Towards the bottom of this page, you now have TLS 1.3
           | illustrated as well.
        
         | rufius wrote:
         | Every book MWL has released has been super helpful in my
         | experience.
         | 
         | Probably one of the best tech writers I've ever encountered. I
         | own most of this books - especially the more BSD specific ones.
        
       | eandre wrote:
       | TLS always felt like a scary beast to me until I started writing
       | Go. The crypto/tls package is amazing and makes doing incredible
       | things with TLS super easy. We're using it in lots of interesting
       | ways behind the scenes for Encore, leveraging Vault, a custom CA,
       | SPIFFE for workload identity and more.
       | 
       | I haven't read the book, but learning more about TLS is easily
       | one of the best time investments I've made.
        
         | rad_gruchalski wrote:
         | > TLS always felt like a scary beast to me until I started
         | writing Go. The crypto/tls package is amazing and makes doing
         | incredible things with TLS super easy.
         | 
         | This x100. I have been recently developing an embedded CA for a
         | gRPC service in golang. Issuing a root, intermediate, server
         | and a client cert for mtls is less than 350 lines of code. It's
         | incredible.
         | 
         | I've written more about it here:
         | https://gruchalski.com/posts/2021-03-28-firebuild-rootfs-
         | grp....
        
       ___________________________________________________________________
       (page generated 2021-04-11 23:01 UTC)