Read on Twitter
A while back, I learned you can include expired root certificates in your certificate chain on your webserver, and the browser won't make a fuzz.
So ...
What else could you stuff in there?
Long-form: https://ma.ttias.be/certificate-chain-stuffing/
Below, a thread!
So ...
What else could you stuff in there?
Long-form: https://ma.ttias.be/certificate-chain-stuffing/
Below, a thread!
The tl;dr: of how certificates work:
Your computer/server comes with a set of root certificates that it trusts, and every certificate will be validated against one of those root certificates.
Your computer/server comes with a set of root certificates that it trusts, and every certificate will be validated against one of those root certificates.
Usually, thereâs a certificate in between, called an intermediate, that chains the SSL certificate of a website, through that intermediary certificate, to the root certificate.
Some websites send along a very old root certificate to their clients.
What if instead of just *one* root certificate, we include - say - 82 root certificates in the chain?
What if instead of just *one* root certificate, we include - say - 82 root certificates in the chain?
To test this, I modified my @caddyserver and instead of using its internal Letâs Encrypt mechanism, I supplied it my own (self-signed) certificate.
The certificate.crt file contains a random selection of 82 other root cert: https://gist.github.com/mattiasgeniar/f5ebf8e9833b37aa5a5af58b1cfc5f43
The certificate.crt file contains a random selection of 82 other root cert: https://gist.github.com/mattiasgeniar/f5ebf8e9833b37aa5a5af58b1cfc5f43
The certificate.crt now weights 132KB in size as opposed to the lean 1.9KB it was before.
And when I reload the webserver ⊠it still just works!
And when I reload the webserver ⊠it still just works!
Why limit it at 83 certs? Well, it's sort-of random, but there's a limit to how many certs will be parsed client-side.
In practice, openssl (and curl's implementation) parses around ~80 certificates. After that, it throws "routines:CONNECT_CR_CERT:excessive
message size" errors.
In practice, openssl (and curl's implementation) parses around ~80 certificates. After that, it throws "routines:CONNECT_CR_CERT:excessive
message size" errors.
This experiment lead to an observation: both Chrome and Firefoxâs network inspector do not show the network traffic generated by the certificate exchange.
If a browser sends 1 certificate or 83, the total network size remains the same in the inspector.
If a browser sends 1 certificate or 83, the total network size remains the same in the inspector.
Whatâs the performance impact?
To be fair, itâs quite small. I would have expected a substantial increase in the time spent in TLS-negotiation, but thatâs not really the case.
I added ~80 certs around 2PM. Things slow down, but not by much.
To be fair, itâs quite small. I would have expected a substantial increase in the time spent in TLS-negotiation, but thatâs not really the case.
I added ~80 certs around 2PM. Things slow down, but not by much.
What can you do with this newly gained knowledge of stuffing extra certs in chains?
Not much I guess ÂŻ\\_(ă)_/ÂŻ
I have some ideas for CTF's or data extraction techniques, if you're interested - read the longer blogpost!
Peace out
https://ma.ttias.be/certificate-chain-stuffing/#what-can-you-do-with-this
Not much I guess ÂŻ\\_(ă)_/ÂŻ
I have some ideas for CTF's or data extraction techniques, if you're interested - read the longer blogpost!
Peace out
https://ma.ttias.be/certificate-chain-stuffing/#what-can-you-do-with-this
