User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0 SeaMonkey/2.32.1 Build ID: 20150208103530 Steps to reproduce: Due to POODLE and the related incidents I am rather pleased that Seamonkey still offers an GUI for enabling / disabling the different TLS versions. But: After restricting Seamonkey to only use TLS1.2 its integrated updater broke. Pointing https://www.ssllabs.com/ssltest/ at aus2-community.mozilla.org revealed the cause: The SSL configuration of that server is horrible outdated and does not support TLS1.2. And much worse: It still support SSLv2! (And SSLv3...) Because I don't know if there are additional checks after the download of a new Seamonkey version, I'm marking this as an security bug, because an attacker can use the FREAK-Attack to impersonate the update server and supply an manipulated update. Actual results: Qualy report on aus2-community.mozilla.org: Overall Rating: F This server supports SSL 2, which is obsolete and insecure. Grade set to F. This server supports insecure Diffie-Hellman (DH) key exchange parameters. Grade set to F. This server supports 512-bit export suites and might be vulnerable to the FREAK attack. Grade set to F. This server is vulnerable to the POODLE attack. If possible, disable SSL 3 to mitigate. Grade capped to C. Certificate uses a weak signature. When renewing, ensure you upgrade to SHA2. The server supports only older protocols, but not the current best TLS 1.2. Grade capped to B. This server accepts the RC4 cipher, which is weak. Grade capped to B. The server does not support Forward Secrecy with the reference browsers. https://www.ssllabs.com/ssltest/analyze.html?d=aus2-community.mozilla.org&hideResults=on Expected results: Similar SSL support like the Firefox server. Qualy report on aus4.mozilla.org: Overall Rating: A- The server does not support Forward Secrecy with the reference browsers. Grade reduced to A-. ... the only thing Qualy complains about is, that IE will not get Forward Secrecy, which seems to be acceptable for an Server that probably only ever sees Mozilla products. ;-) https://www.ssllabs.com/ssltest/analyze.html?d=aus4.mozilla.org&hideResults=on
Bug 960665 is unrelated.... Bug 1119950 should solve this, but since we have cert pinning in SeaMonkey is not an instant deploy. We'll need to also verify against this issue at time of preparing to deploy (shouldn't be hard, but is certainly warranted).
p.s. for drive-by's, only SeaMonkey uses aus2-community, and it is a community run server, MoCo just helps us with the cert stuff relating to it.
fwiw this got marked core-sec, but looks like it was because it was the only remaining restriction group for this component. It needs a restriction but is *not* a "product sec" that needs any sort of tracking
Not an issue that's useful to hide.