Bug #3878
Mitigate POODLE
| Status: | In Progress | Start date: | 10/16/2014 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | lee | % Done: | 0% | |
| Category: | - | Spent time: | - | |
| Target version: | - | |||
| Component: |
Description
Nathan said you were working on it, but just in case, I thought I'd create an issue to discuss.
From what I understand, the current fix for POODLE is to disable SSLv3 support:
https://linode.com/docs/security/security-patches/disabling-sslv3-for-poodle
Main thing I found (while going through setup and working to understand the system) was this -- tls_method = sslv23
http://git.io/WhWuxA
I guess we should either switch that to sslv2 or use tlsv1 (vaguely remember hearing that the latter won't work for encrypted calls wtih srtp, but not sure).
Anyhow, interested to learn about this stuff, so I'm eager to hear what you think needs to be done to mitigate POODLE :)
History
#1 Updated by patcon over 3 years ago
Sorry, this is OSTN for anyone reading along. didn't realize issue tracker was org-wide
#2 Updated by lee over 3 years ago
- Status changed from New to Closed
#3 Updated by patcon over 3 years ago
Ok, so as I'm reading around, it seems the considerations in play are that:
- SSLv3 is insecure in light of POODLE
- SSLv23 uses v3, so it's bad
- SSLv2 is considered old and only for old clients, and assumed insecure (?)
- TLSv1x is the secure option now, but since its TCP, is slower and previously not recommended for Z/SRTP, which recommends the light weight of UDP found with SSLv2/3
- TLSvx also seems to be more finnicky and difficult to configure, as various docs seem to be impressing on me
Am I getting that right? So we're kinda deciding between a slower and more cumbersome TLSvx, or a less secure and perhaps deprecated SSLv2?
Or.. do we just upgrade openssl and everything is happy and shiny?
http://threatpost.com/openssl-releases-patch-for-poodle-attack/108875
#4 Updated by patcon over 3 years ago
Cool. (Just saw the tweet link.) That's awesome Lee! Thanks for that and everything
I'm interested in how the fix was applied and works if it's something easily communicated. Or if the fix will show up in chef-ostn, then I can just look there and understand
#5 Updated by lee over 3 years ago
Oops, I edited it on the server. You can grep the nginx config for the string "v3" and delete the line that reads sslv3. Restart nginx, that'll do it.
#6 Updated by patcon about 3 years ago
Thanks!
So if we're using the default for ssl_ciphers, then it's `HIGH:!aNULL:!MD5` like it says in the wiki? If `openssl ciphers -v 'HIGH:!aNULL:!MD5:` still shows options with SSLv3, does that mean anything? Or is it irrelevant because we don't have SSLv3 in the ssl_protocols directive?
And speaking of ssl_protocols directive, did we have any reason to just use `TLSv1`? Or could we also use TLSv1.1 and TLSv1.2?
https://github.com/patcon/chef-ostn/blob/easier-deploy/cookbooks/webapp/templates/default/nginx-site.erb#L38
Thanks!
#7 Updated by lee about 3 years ago
- Status changed from Closed to In Progress
I'm more concerned with the SIP-TLS stack present in Kamailio. There are some issues with client applications automatically switching protocols, which are breaking. I believe this should be the primary goal for SSL auditing. The browser HTTPS connection is secondary to the voice component. I'll reopen this until there's a full stack resolution.