4 ms·

The idea is good, as far as I understand TLS however, the cert / asymmetric key is only used prove the identity/authenticity of the cert and thus the host for t

by kro 2y ago

The idea is good, as far as I understand TLS however, the cert / asymmetric key is only used prove the identity/authenticity of the cert and thus the host for this session. But the main content is not signed / checksummed with it, but rather a symmetrical session key, so one could probably manipulate this in the packet dump anyway. I read about a Google project named SXG (Signed HTTP exchanges) that might do related stuff, albeit likely requiring the assistance of the publisher

ethbr1 2y ago
To extend this to archival integrity without cooperation from the server/host, you'd need the client to sign the received bytes. But then you need the client to be trusted, which clashes with distributing. Hypothetically, what about trusted orgs standing up an endpoint that you could feed a URL, then receive back attestation from them as to the content, then include that in your own archive? Compute and network traffic are pretty cheap, no? So if it's just grabbing the same content you are, signing it, then throwing away all the data and returning you the signed hash, that seems pretty scalable? Then anyone could append that to their archive as a certificate of authenticity.
catlifeonmars 2y ago
Reminds me of timestamp protocol and timestamp authorities. Not quite the same problem, but similar enough to have a similar solution. https://www.ietf.org/rfc/rfc3161.txt https://www.ietf.org/rfc/rfc3161.txt
Intralexical 2y ago
"TLS-N", "TLS Sign", and maybe a couple others were supposed to add non-repudiation. But they didn't really go anywhere: https://security.stackexchange.com/questions/52135/tls-with-non-repudiation-what-happened-with-tls-sign https://security.stackexchange.com/questions/52135/tls-with-... https://security.stackexchange.com/questions/103645/does-ssl-tls-provide-non-repudiation-service/ https://security.stackexchange.com/questions/103645/does-ssl... There are some special cases, like I think certain headers for signing e-mails, that do provide non-repudiation. For that, `tcpdump` with `SSLKEYLOGFILE` will probably get you started on capturing what you need.

by kro 2y ago

ethbr1 2y ago

To extend this to archival integrity without cooperation from the server/host, you'd need the client to sign the received bytes. But then you need the client to be trusted, which clashes with distributing. Hypothetically, what about trusted orgs standing up an endpoint that you could feed a URL, then receive back attestation from them as to the content, then include that in your own archive? Compute and network traffic are pretty cheap, no? So if it's just grabbing the same content you are, signing it, then throwing away all the data and returning you the signed hash, that seems pretty scalable? Then anyone could append that to their archive as a certificate of authenticity.

catlifeonmars 2y ago

Reminds me of timestamp protocol and timestamp authorities. Not quite the same problem, but similar enough to have a similar solution. https://www.ietf.org/rfc/rfc3161.txt https://www.ietf.org/rfc/rfc3161.txt

Intralexical 2y ago

"TLS-N", "TLS Sign", and maybe a couple others were supposed to add non-repudiation. But they didn't really go anywhere: https://security.stackexchange.com/questions/52135/tls-with-non-repudiation-what-happened-with-tls-sign https://security.stackexchange.com/questions/52135/tls-with-... https://security.stackexchange.com/questions/103645/does-ssl-tls-provide-non-repudiation-service/ https://security.stackexchange.com/questions/103645/does-ssl... There are some special cases, like I think certain headers for signing e-mails, that do provide non-repudiation. For that, `tcpdump` with `SSLKEYLOGFILE` will probably get you started on capturing what you need.