Michael Grant <mgr...@grant.org> wrote: > Nifty, been a while since I used the LD_PRELOAD trick myself.
> This whole thing has been bothering me over the last couple days. Why > are so few people having this issue? 18 or so posts on this, only 3 > or so of us have done anything about this. I backed out libssl (and > pinned it). Reco makes a LD_PRELOAD hack. Sven recompiles OpenSSL > with patch removed. > Did this or will this patch get into Stretch Stable yet as a security > patch? If yes, then won't there be hundreds if not thousands of > people screaming about this? No, it won't. > I am wondering why it's so few of us who seem to be affected? I > suspect it's because 1) we're running Debian Testing and most of the > Debian world runs Stable, 2) more and more people are turning to gmail > and outlook.com instead of running their own mail servers and 3) the > few remaining people who do go to the trouble of using Debian Testing > as a mail server probably wouldn't care that much about getting TLS > set up with imap/pop/smtp working at all. Probably. > If this patch won't go to Stretch as a security fix, then the world is > hidden from this until Buster comes out in about 2 years. Exactly. Read the discussion(s) in debian-devel about this. The last idea was to have Buster semi-broken until shortly before the release and then switch back on TLS1.0 and TLS1.1 support. > But what's going to happen if there is some other security fix which > is needed in Stretch's libssl1.1 (1.1.0f-3)? Will there be some fork > of this library for Stretch without this patch? Or will at that time > this patch get swept in with some other future security patch and the > hit the wild with Stretch stable + security patches? Since this patch is a Debian-only change and in no way included in upstream in any way, a security update for Stretch will not contain this change. > By pinning this library at 1.1.0f-3 on my system, I feel somehow I've > done the wrong thing. We all habe done the wrong thing by diverting from the main development path of Buster. > I started to think I should put in Reco's hack until these Windows 7 > and Mac 10.11 users move to more modern releases or MS and Apple send > out patches for their older stuff. Or maybe I should follow Stretch > (and it's security fixes) for only this package instead of pinning it > to this version. Pinning this package to Stretch will not work very long, I think. At some point Stretch and Buster will have diverged to far for the library from Stretch being compatible with the rest of Buster. > And by the way, this isn't just limited to mail clients. It's also > affecting MTAs. I see a large number of mail servers connecting to my > server that only do TLSv1 and TLSv1.1. When they can't do TLS, I > think they just fall back to SMTP in the clear. So the problem isn't > obvious to any user and mail in general is just less secure. It is far more problematic for WLAN+freeradius. Currently ~50% of Android phones can't use TLS1.2 for the SSL handshake during the EAP phase of the WPA-Enterprise login. Also Windows 7 and Windows 8/8.1 are unable to connect because of the same problem. > While I am totally sympathetic to getting the world onto TLSv1.2 and > greater, this seems like a support disaster waiting to happen. Oh yes, absolutley. I admin many servers and infrastructure in an University network and if this change happens to be included in Buster, I will either have to recompile OpenSSL forever, backing out the change, or, more likely, switch all systems to a different distribution, probably CentOS. I can't just tell the majority of my students to get a new phone or laptop because some Developer thaught he could pressure the world to rotate in a different direction by decree. In two years when Buster is release, adoption of TLS1.2-only will not be high enough to just switch off everything else. > What is the right way for an admin to handle this problem on Debian Testing? Don't use Debian Testing on production systems. Grüße, Sven. -- Sigmentation fault. Core dumped.
