5

In December there was a new attack surface of POODLE against TLS 1.0 (think this also covers 1.1 and 1.2?). Anyway, as a system administrator for Windows Server 2008/2012 what can we do do prevent this?

Lots of articles I read stated that due to CBC block cipher used in SSL this causes issues and I saw a great article someone wrote on this website that explained it well...but at all times I always read "this does not affect TLS"...but,now it seems it does affect it.

From reading various articles it seems like a lot state "some implementations of TLS are affected"...what does that mean???! What specific implementation are they talking about?

We have already disabled SSL 3.0 back in October but trying to understand what else we can do to prevent the new attack on TLS?

I cannot find anything apart from some articles that explain that F5 and some A10 systems or websites were affected but nothing as to how to fix this on Windows Servers.

I have also seen issues whereby the advice is not to use older browsers - I am not really interested in that as I look after servers and not desktop space and the desktop guys will know what browsers they have. I know servers have browsers so I guess I am interested a bit but internet access on servers are disabled in our company...unless you're on terminal servers..

Specifically is there anything in the registry under TLS keys that I need to change etc? I have no idea what will break if we disable TLS 1.0 (but if this newest POODLE attack affects TLS 1.1 and 1.2 then we cannot turn the whole thing off!).

Improve this question

1 Answer 1

Reset to default
5

Some implementations of TLS 1.0 did not properly validate the padding as required by the TLS specification. This led to a situation in which the POODLE bug could be leveraged against TLS 1.0, despite the fact that it should be secure against the attack. Later versions of TLS (i.e. 1.1 and 1.2) are inherently secure against POODLE and other padding oracle issues because they authenticate the encrypted message (CBC-then-MAC) rather than authenticating the plaintext (MAC-then-CBC) (EDIT: That bit was wrong, see Thomas Pornin's comment below)

As far as I know, the only major implementations affected are in equipment from F5 Networks, A10 Networks, and Cisco. The SSL Labs scanner checks for the bug, but it can only target internet-facing IPs. The Windows SSL stack, as far as I can tell, properly implements the padding checks in TLS 1.0 and therefore isn't vulnerable to the TLS variant of POODLE. As such, you shouldn't need to do anything.

Improve this answer
7
  • 3
    TLS 1.1 and 1.2 still use MAC-then-encrypt. TLS 1.2 optionally supports cipher suites that use a better method (GCM) but in many case, MAC-then-encrypt (with CBC) is still used. However, people who do a sloppy job at implementing TLS 1.0 rarely implement 1.1 and 1.2 at all. What TLS 1.1+ provides is a per-record IV that protects against exploitation of some of the CBC issues (BEAST...) but it does nothing against the issue leveraged by POODLE.
    – Thomas Pornin
    Commented Mar 5, 2015 at 11:56
  • My bad - I honestly thought it was encrypt-then-MAC. Why are we still using that crappy construction!? shakes head ... Also, does that mean I'm wrong then? POODLE can still work against TLS1.1/1.2 if they do the padding badly?
    – Polynomial
    Commented Mar 5, 2015 at 12:00
  • Prolonged use of MAC-then-encrypt was for "backward compatibility". I suppose that the people who designed TLS 1.1 and 1.2 assumed that there was 0% probability of adoption of the new versions by existing libraries if they asked for too large a change of the protocol... Anyway, TLS 1.1 and 1.2 are also vulnerable to POODLE if they are poorly implemented. The TLS 1.0, 1.1 and 1.2 specification all say explicitly that the client MUST check all padding bytes; if someone disregards that "MUST" for TLS 1.0 implementation, he can conceptually disregard it when doing TLS 1.1 and 1.2 as well.
    – Thomas Pornin
    Commented Mar 5, 2015 at 12:11
  • 1
    In any case, even the best designed protocol can always be translated into vulnerable implementations if the developer chooses not to follow the specification. There is very little protocol designers can do against that.
    – Thomas Pornin
    Commented Mar 5, 2015 at 12:12
  • Oh, joy. Time to go update our standard recommendations then! Maybe we'll get a sensible TLS spec by 2035.
    – Polynomial
    Commented Mar 5, 2015 at 12:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .