Signing TLS handshakes inside a TPM
bschaatsbergen.com
Signing TLS handshakes inside a TPM
1–10 of 49 posts
Re: Signing TLS handshakes inside a TPM
#2Sounds interesting; too bad all we get is text made up by an LLM rather than any of the author's insights.
Re: Signing TLS handshakes inside a TPM
#3Sounds interesting; too bad all we get is text made up by an LLM rather than any of the author's insights.
Yeah I was interested for the first few paragraphs, then all of a sudden I get hit with two "genuinely"s and a
> That’s the third property, and it’s the one that decides this.
and I gave up at that point.
Re: Signing TLS handshakes inside a TPM
#4Let's hope this doesn't get picked up by the (corporate) masses... the last thing I want is my browser offering personal TLS certificates to every server I visit as some kind of identity verification or fingerprint/tracking.
It's bad enough that ssh does this by default with all your keys.
Re: Signing TLS handshakes inside a TPM
#5Nothing new here, attested TLS was being discussed in IETF for quiet sometime right?
https://datatracker.ietf.org/doc/draft-fossati-tls-attestati... https://www.youtube.com/watch?v=MF9AwkMJOlw
Re: Signing TLS handshakes inside a TPM
#6Let's hope this doesn't get picked up by the (corporate) masses... the last thing I want is my browser offering personal TLS certificates to every server I visit as some kind of identity verification or fingerprint/tracking. It's bad enough that ssh does this by default with all your keys.
Client TLS is rather unusable on the Internet by a typical random end user visiting a random public site, so that should at least keep the specific scenario you describe at bay.
Re: Signing TLS handshakes inside a TPM
#7Let's hope this doesn't get picked up by the (corporate) masses... the last thing I want is my browser offering personal TLS certificates to every server I visit as some kind of identity verification or fingerprint/tracking. It's bad enough that ssh does this by default with all your keys.
Client TLS is rather unusable on the Internet by a typical random end user visiting a random public site, so that should at least keep the specific scenario you describe at bay.
Currently yes, but there's not much stopping Chrome etc. from adding a new feature that has a way of presenting a client certificate to a website in a backwards-compatible manner.
Of course the website itself would need to support that, but it's all possible in time.
Re: Signing TLS handshakes inside a TPM
#8Let's hope this doesn't get picked up by the (corporate) masses... the last thing I want is my browser offering personal TLS certificates to every server I visit as some kind of identity verification or fingerprint/tracking. It's bad enough that ssh does this by default with all your keys.
[dead]
Re: Signing TLS handshakes inside a TPM
#9Earlier quoted context omitted.
Client TLS is rather unusable on the Internet by a typical random end user visiting a random public site, so that should at least keep the specific scenario you describe at bay.
Currently yes, but there's not much stopping Chrome etc. from adding a new feature that has a way of presenting a client certificate to a website in a backwards-compatible manner. Of course the website itself would need to support that, but it's all possible in time.
Chrome would be more likely to implement a persistent and identifiable (to Google alone) tracking cookie replacement and ship it worldwide, which iirc they did — and then cancelled, of course. They seem to be focusing instead on improved tracking of Android users from the kernel up, rather than browsers from the headers down; GrapheneOS is, presumably, viewed as a serious threat to their advertising revenue.
https://privacysandbox.google.com/blog/update-on-plans-for-p...
Re: Signing TLS handshakes inside a TPM
#10Nothing new here, attested TLS was being discussed in IETF for quiet sometime right? https://datatracker.ietf.org/doc/draft-fossati-tls-attestati... https://www.youtube.com/watch?v=MF9AwkMJOlw
That's right, I'm learning in public here. That draft is a different direction though, they change the handshake: new TLS extensions carry the evidence, and the far end appraises the platform during the connection.
What I'm doing changes nothing on the wire, the verifying side has no idea a TPM is involved. In RATS (https://www.rfc-editor.org/rfc/rfc9334.html) we prove a machine is sound by measuring it and appraising the evidence. But after attestation the usual thing is to hand the machine a short-lived identity saying it is attested, and when that machine then authenticates over mTLS to something like an HSM, the thing that gives that machine its identity is a private key in a file. That bothered me. What I want is to tie the key in the TPM to the evidence of the confidential VM at issuance time, and let that be the identity the machine carries afterwards. Working notes while implementing RFC 9334.