3 ms·

There are pretty big mistakes to be made on the other side of this philosophy as well. If you need to solve some cryptographic problem which is not exactly the

by brl 18y ago

There are pretty big mistakes to be made on the other side of this philosophy as well. If you need to solve some cryptographic problem which is not exactly the same as something which has already been designed, implemented, and reviewed by competent cryptographers, then you essentially need to create a new protocol and accept all the pitfalls which that entails. PGP seems to be a popular 'primitive' to try to roll your own broken crypto protocol out of. Exhibit A: http://enigform.mozdev.org/ http://enigform.mozdev.org/ Exhibit B: http://web.monkeysphere.info/ http://web.monkeysphere.info/ Even SSL/TLS is not easy to use correctly (while understanding all the risks) for purposes other than what it was originally designed for: Preventing credit card numbers from being sniffed between a browser and a web merchant.

tptacek 18y ago
Design a transport security protocol that is different in some way from TLS, and a good chunk of those differences are going to be vulnerabilities that the TLS designers figured out that you missed. SSLv1 may have been originally designed for securing credit cards, but I'm not sure that argument survives a close read of TLS; why waste time with mutual authentication, with forward secrecy, with a custom record layer, with arbitrary length certificate signing chains, etc etc etc. You might be surprised at the number of systems that leverage TLS successfully on ports other than 443. We probably agree; no matter how you choose to implement crypto security in a system, you're probably worse off for trying.
- brl 18y ago
  Forward secrecy was one of the important mistakes I had in mind actually. If you use TLS naively, you have none. You probably didn't even realize you needed it. Verifying certificates correctly is not so easy to get right either, if you can even figure out what PKI means for your particular application in the first place.
  - tptacek 18y ago
    Certificates are a lot like git branching. They're intimidating if you consider them in their entirety, but simple if you stick to your old use cases. Enterprise apps make good use of certificates. A common use case is to set up a private CA (a three-line shell script) and issue internal certs to all endpoints in a system; you can then do crypto-strong access control just by checking signatures. This is approximately to PKI what "using git just like you used Subversion" is to git. Another place where TLS has been a huge win is in wireless security; EAP-TLS with mutual certificate auth is the de facto corporate wireless security standard now.

by brl 18y ago

tptacek 18y ago

Design a transport security protocol that is different in some way from TLS, and a good chunk of those differences are going to be vulnerabilities that the TLS designers figured out that you missed. SSLv1 may have been originally designed for securing credit cards, but I'm not sure that argument survives a close read of TLS; why waste time with mutual authentication, with forward secrecy, with a custom record layer, with arbitrary length certificate signing chains, etc etc etc. You might be surprised at the number of systems that leverage TLS successfully on ports other than 443. We probably agree; no matter how you choose to implement crypto security in a system, you're probably worse off for trying.

brl 18y ago
Forward secrecy was one of the important mistakes I had in mind actually. If you use TLS naively, you have none. You probably didn't even realize you needed it. Verifying certificates correctly is not so easy to get right either, if you can even figure out what PKI means for your particular application in the first place.
- tptacek 18y ago
  Certificates are a lot like git branching. They're intimidating if you consider them in their entirety, but simple if you stick to your old use cases. Enterprise apps make good use of certificates. A common use case is to set up a private CA (a three-line shell script) and issue internal certs to all endpoints in a system; you can then do crypto-strong access control just by checking signatures. This is approximately to PKI what "using git just like you used Subversion" is to git. Another place where TLS has been a huge win is in wireless security; EAP-TLS with mutual certificate auth is the de facto corporate wireless security standard now.