Bug #3878

Mitigate POODLE

Added by patcon over 3 years ago. Updated about 3 years ago.

Status:In ProgressStart date:10/16/2014
Priority:NormalDue date:
Assignee:lee% Done:


Category:-Spent time:-
Target version:-


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:

Main thing I found (while going through setup and working to understand the system) was this -- tls_method = sslv23

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 :)


#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?

#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


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?


#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.

Also available in: Atom PDF