11
top 11 comments
sorted by: hot top controversial new old
[-] cron@feddit.org 1 points 6 hours ago

Does anyone know how many corporations have the technical ability to inspect TLS 1.3?

[-] slazer2au@lemmy.world 2 points 3 hours ago

Only place I have seen is when an enterprise CA is used to mitm the session.

Firewall vendors use to claim tls1.3 decryption by forcing the sessions down to 1.2

[-] hperrin@lemmy.world 2 points 3 hours ago
[-] cron@feddit.org 1 points 3 hours ago

With an enterprise CA this is not a huge trouble, but not exactly easy either.

[-] hperrin@lemmy.world 2 points 2 hours ago* (last edited 2 hours ago)

The CA just signs the certificate. They don’t have access to the private key, and thus can’t decrypt the key exchange.

The key exchange is the only thing decrypted by the private keys. From that point on, everything is encrypted and decrypted by the agreed upon cypher using the exchanged key, which is randomly generated for each session.

[-] cron@feddit.org 2 points 1 hour ago

Surely they can do a man-in-the-middle attack and gemerate the required private keys and certs on the fly.

[-] lurch@sh.itjust.works 1 points 33 minutes ago

this only works, if the client doesn't know the server yet or disregards an already known key (you know, like SSH or web browsers telling you the key has changed)

[-] hperrin@lemmy.world 2 points 55 minutes ago

They could pretend to be any domain, yes, but you asked about inspecting a TLS stream, and afaik, there’s no way to do that without the private key. Once the TLS handshake begins, there wouldn’t be a chance for a man in the middle, so that kind of attack would have to be done before the connection is established.

[-] jaybone@lemmy.world 1 points 2 hours ago

Not that it really matters to this conversation but seems like you would know, so I’ll ask because I’m curious…

Is that randomly generated per session key generated by the remote host ssh server? Is it a symmetric key (maybe for performance purposes)?

[-] hperrin@lemmy.world 1 points 1 hour ago* (last edited 1 hour ago)

Technically, either side can request that the other generate a key and use that one, and it will cost an additional round trip. But generally in practice, each side generates their own key and tells the other side that it will be using that key.

Yes, those keys are for symmetric encryption, and yes, it’s for performance. It’s way faster to just exchange keys with asymmetric encryption rather than do the whole stream.

Also, I think you meant SSL, not SSH. SSH Uses a different key exchange protocol.

I love cryptography. :)

[-] lnxtx@feddit.nl 1 points 6 hours ago

I will test it if it works with Firepower (not blocking it).

this post was submitted on 06 Oct 2024
11 points (100.0% liked)

Cybersecurity

5485 readers
77 users here now

c/cybersecurity is a community centered on the cybersecurity and information security profession. You can come here to discuss news, post something interesting, or just chat with others.

THE RULES

Instance Rules

Community Rules

If you ask someone to hack your "friends" socials you're just going to get banned so don't do that.

Learn about hacking

Hack the Box

Try Hack Me

Pico Capture the flag

Other security-related communities !databreaches@lemmy.zip !netsec@lemmy.world !cybersecurity@lemmy.capebreton.social !securitynews@infosec.pub !netsec@links.hackliberty.org !cybersecurity@infosec.pub !pulse_of_truth@infosec.pub

Notable mention to !cybersecuritymemes@lemmy.world

founded 1 year ago
MODERATORS