4 ms·

> Why should I use OpenSSL for TLS termination when formally validated alternatives exist? Oh please do share! (spoiler: alternatives which enable side channel

by wfn 13y ago

> Why should I use OpenSSL for TLS termination when formally validated alternatives exist? Oh please do share! (spoiler: alternatives which enable side channels because the pretty compiled-optimized-code (that is generated from source code that itself may feature immutable data etc. with no side effects) is ripe with leaks via cpu branching, caching, etc etc do not count.) This is not a spiteful rhetorical inquiry, by the way!

AaronFriel 13y ago
Those side-channel attacks are largely theoretical. OpenSSL and RSA in general are vulnerable to side channel attacks, because many of the fundamental operations are not constant-time. That can change eventually, but RSA is difficult to write in a constant-time manner. OpenSSL certainly has had its fair of lab-demonstrated side-channel attacks, but I don't think anyone has been able to demonstrate their use in virtualized hosting environments against arbitrary other tenants. Side channel attacks once you've already got code running on the same operating system as the target are much easier. But if you can get arbitrary code to execute on the same machine running OpenSSL, you probably already have their keys. So, I think the criticism to OpenSSL is valid. Why use it when it seems there are less bad alternatives? A lot of it comes down to network effects, inertia, and licensing. That's a much better answer than side-channel attack surface area, which all RSA implementations share :)
- wbl 13y ago
  Nope: you can exploit the timing attacks from across a network link in AES. DJB did this long, long ago. Furthermore, I believe OpenSSL has constant-time RSA, but you can always use ECDSA for which constant time implementations in C exist. (I wrote one, but I still need to switch the hash function to SHA256 and add the unnecessary encoding steps to the output, so consider it a PoC).
  - AaronFriel 13y ago
    Are you sure? Searching for "side channel OpenSSL" reveals a majority of the attacks are against ECDSA. Of course, searches aren't the best measure of vulnerability, it's just an indication of popularity.
    - wbl 13y ago
      http://cr.yp.to/antiforgery/cachetiming-20050414.pdf http://cr.yp.to/antiforgery/cachetiming-20050414.pdf ECDSA is nice because you can use partial nonce recovery+lattice reduction. Furthermore recent Intel chips have AES instructions.
- jude- 13y ago
  > Those side-channel attacks are largely theoretical. Before you write secure software, you have to consider who your adversaries are, and what they are capable of doing. Side-channel attacks over the network are definitely practical [1] [2] [3]. If you're making even a basic SaaS product, you should assume your adversaries can carry out the above. You should assume that by now, even lowly script kiddies have side-channel exploits in his arsenal. [1] Relevant paper (2010) http://www.informatics.indiana.edu/xw7/papers/WebAppSideChannel-final.pdf http://www.informatics.indiana.edu/xw7/papers/WebAppSideChan... [2] Ed Felton's analysis on [1] [3] Bruce Schneier's analysis on [1]
wbl 13y ago
PolarSSL has been validated with FRAMA-C by a company. Unfortunately you have to pay to see the results, and they use blinding for bignum arithmetic, not constant-time. (But they do have a decent curve implementation). http://trust-in-soft.com/news/ http://trust-in-soft.com/news/ To remove side channels and preserve validation, you need to be slightly clever. You validate that a C implementation of one of the functions does the same thing as a function in the validated package, then swap them in the build output. This can be done for miTLS. Your validation of the C part is much more limited in scope than the whole thing.
- wfn 13y ago
  > To remove side channels and preserve validation, you need to be slightly clever. You validate that a C implementation of one of the functions does the same thing as a function in the validated package, then swap them in the build output. This can be done for miTLS. Aha, this is interesting! Thanks for the link.

by wfn 13y ago

AaronFriel 13y ago

Those side-channel attacks are largely theoretical. OpenSSL and RSA in general are vulnerable to side channel attacks, because many of the fundamental operations are not constant-time. That can change eventually, but RSA is difficult to write in a constant-time manner. OpenSSL certainly has had its fair of lab-demonstrated side-channel attacks, but I don't think anyone has been able to demonstrate their use in virtualized hosting environments against arbitrary other tenants. Side channel attacks once you've already got code running on the same operating system as the target are much easier. But if you can get arbitrary code to execute on the same machine running OpenSSL, you probably already have their keys. So, I think the criticism to OpenSSL is valid. Why use it when it seems there are less bad alternatives? A lot of it comes down to network effects, inertia, and licensing. That's a much better answer than side-channel attack surface area, which all RSA implementations share :)

wbl 13y ago
Nope: you can exploit the timing attacks from across a network link in AES. DJB did this long, long ago. Furthermore, I believe OpenSSL has constant-time RSA, but you can always use ECDSA for which constant time implementations in C exist. (I wrote one, but I still need to switch the hash function to SHA256 and add the unnecessary encoding steps to the output, so consider it a PoC).
- AaronFriel 13y ago
  Are you sure? Searching for "side channel OpenSSL" reveals a majority of the attacks are against ECDSA. Of course, searches aren't the best measure of vulnerability, it's just an indication of popularity.
  - wbl 13y ago
    http://cr.yp.to/antiforgery/cachetiming-20050414.pdf http://cr.yp.to/antiforgery/cachetiming-20050414.pdf ECDSA is nice because you can use partial nonce recovery+lattice reduction. Furthermore recent Intel chips have AES instructions.
jude- 13y ago
> Those side-channel attacks are largely theoretical. Before you write secure software, you have to consider who your adversaries are, and what they are capable of doing. Side-channel attacks over the network are definitely practical [1] [2] [3]. If you're making even a basic SaaS product, you should assume your adversaries can carry out the above. You should assume that by now, even lowly script kiddies have side-channel exploits in his arsenal. [1] Relevant paper (2010) http://www.informatics.indiana.edu/xw7/papers/WebAppSideChannel-final.pdf http://www.informatics.indiana.edu/xw7/papers/WebAppSideChan... [2] Ed Felton's analysis on [1] [3] Bruce Schneier's analysis on [1]

wbl 13y ago

PolarSSL has been validated with FRAMA-C by a company. Unfortunately you have to pay to see the results, and they use blinding for bignum arithmetic, not constant-time. (But they do have a decent curve implementation). http://trust-in-soft.com/news/ http://trust-in-soft.com/news/ To remove side channels and preserve validation, you need to be slightly clever. You validate that a C implementation of one of the functions does the same thing as a function in the validated package, then swap them in the build output. This can be done for miTLS. Your validation of the C part is much more limited in scope than the whole thing.

wfn 13y ago
> To remove side channels and preserve validation, you need to be slightly clever. You validate that a C implementation of one of the functions does the same thing as a function in the validated package, then swap them in the build output. This can be done for miTLS. Aha, this is interesting! Thanks for the link.