Hacker News new | past | comments | ask | show | jobs | submit login

  why not use a library that does TLS with an AEAD cipher, like AES-GCM?
Some possible reasons:

* lack of confidence in TLS's design and designers (for example, TLS1.2 still allows compression and fails to counsel against its use).

* TLS has far too many options. I want a secure channel. I don't want a secure channel toolkit.

* TLS tends to be paired with a broken and discredited root-of-trust infrastructure (which often gives the misleading impression that TLS itself was broken).

(nb. I don't have any evidence that the AEAD TLS1.2 ciphersuites are broken, I'm playing devil's advocate here.)

Regarding your 'new cryptosystems' point: I agree, and its completely and frustratingly hopeless. But that's why the world needs a decent secure channel standard with good security bounds, and no knobs on the side which break confidentiality or integrity, and no backwards-insecurity ability.




* You should have even less confidence in new cryptosystems.

* Downthread, I suggested that TLS doesn't have as many extraneous options as it appears.

* If you can specify AES-GCM, it is even easier to specify not using default CA roots.

* Using an AEAD cipher removes crypto logic from the SSL protocol (the order of operations and message formatting for getting a block cipher to work with a hash-based MAC) and moves it into the block cipher mode, which (unlike TLS) is NIST-standardized.


Is there a problem with the body content of an http response being compressed, or is it mainly a header thing?


There can be if a secret is on the same page as text under the attacker's control. The attacker can run a hidden JavaScript reload attack on the page, the fiddle with the text under their control until compression is maximized.




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: