- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
I can't imagine any reasons that "Compliance" would insist on no TLS. More likely it would be yes of course TLS.
Oh, except for the reasons why lots of big banks hate TLS 1.3. It's really hard to MitM it, so their compliance peeps can't spy on their own employees.
Admin
Frist for compliance reasons.
Admin
Senocd for compliance reasons
Admin
All you need to read TLS 1.3 traffic is an update of your dictator-friendly proxy server.
https://www.symantec.com/products/ssl-visibility-appliance
Admin
Maybe it's "compatibility-with-older-software compliance"?
Admin
Before disabling any form of security I'd be asking what those compliance reasons were. Measure twice, cut once.
Admin
"We need to disable TLS for compliance reasons."
Pretty much stopped reading right there, that's quite enough WTF for one day.
Admin
Tee hee, Just went through this (removing TLSv1.0 support in favor of TLS1.1,2,3) with a web site remarkably close in tech to the one in the story. It was ridiculously hard and expensive.
The real WTF? Bank, healthcare, and fintech employees stuck on IE9 and IE8.
Admin
I'm willing to bet "turn off TLS" was a mis-translation between security and the manager. They probably said turn off TLS versions 1.0 and 1.1, and the manager stopped listening after TLS. I've seen the same thing happen, that's why I now word it as "You can only use TLS1.2 and higher."
Admin
I actually think you're onto something. We all know how stupid people are, especially the average manager.
Admin
But IE 10 doesn't run on Windows 98!
Admin
[quote] “compliance” reasons be damned. [\quote]
Sounds about right. No one involved in this cluster fuck gave a shit about compliance OR user security.
Admin
I know. My company makes equipment that can do this, although not at the moment for TLS 1.3.
Admin
That's probably a good thing, overall.
I have a DVD at home of XP-Pro with SP2 baked in, and I wanted to check something with it. For complicated reasons, I never actually activated it, and now I can't because it can't do HTTPS, or only just. I put it on a VM and found that only a very, very few HTTPS sites still use root certificates that IE knows about, and something in the VM triggered my UTM's "I detected SSLv2" alarms...
Admin
TRWTF is needing to disable TLS for "compliance"... and Keith not asking for more information.
I imagine it was, as others have suggested, a case of disabling outdated TLS versions, and by "disable" they meant "disallow" rather than "use unencrypted connections". And, as usual, the boss who knows nothing about technology got the story wrong.
Admin
Add me to those who think the disable requirement was mangled by a non-technical person.
Admin
I've found a disturbing lack of overlap between "non-techincal person" and "understands what TLS is."
Admin
Oops, I meant to say:
I've found a disturbing lack of overlap between "techincal person" and "understands what TLS is."
Admin
'The real WTF? Bank, healthcare, and fintech employees stuck on IE9 and IE8.'
That's just perfectly normal. Bank, healthcare, and fintech always have the sh#@iest most insecure systems (bad password policies guaranteed!). You can often find 'Copyright 2002' (or some time in the 2000s) in the page headers, and they've been crufting ever since.
Which I guess is an industry WTF.
Admin
Compliance is more than just security. Sometimes it's adhering to retarded policies passed down from regulations or service users that adhere to even more regulations. In some fantasy world it's not unthinkable that some regulations forbade the use of TLS for client-facing connections.
But I agree that PHB mismanagement is the more likely scenario
Admin
In some cases, it's internal compliance rather than regulatory, where (as hinted above, but very obliquely) the compliance folks need to have a way to make sure that traders are playing by the rules (especially the rules about insider information rather than the detailed and frequently bizarre rules about exchange interactions, which the exchanges will tend to enforce anyway), and that means spying on their connections somewhere.
In earlier versions of TLS and SSL, it was relatively easy to do, but 1.3 makes it significantly harder without being an actual man in the middle, and that can lead to "well, TLS 1.0 and 1.1 are going away now, and 1.2 will be going away some time fairly soon, and 1.3 is hard to spy on, and we 'need' to spy on the connections, therefore no TLS at all" as a policy decision.
Admin
"There was no way to know for sure what code was in Git and what was in production and how they didn’t match."
Oh, if only there were some way to pull code from git and compare it to the running system!
ε(´סּ︵סּ`)з
Admin
TRWTF is "two parallel development streams: one tracked in Git, and one done by editing files and compiling right on the production server"
Admin
TRWTF is fiddling with global setting instead of locally fixing the bug.
Why didn't he replace that stupid HTTP client call with a direct call to the method that produces the PDF?
Admin
"There was no way to know for sure what code was in Git and what was in production and how they didn’t match."
I don't know what job this guy has, but programmers have tools designed explicitly for finding differences and merging them.
The one I have installed right now is called "meld".
Admin
Wait, there is some misinformation in there... URL parameters are encrypted in HTTPS requests. In fact, the only part not encrypted is the hostname, because that's needed by the server to figure out which certificate it should use for the request.
Admin
I might be missing something, but I'm not seeing the code where HTTPS is required.
I'm seeing an overall-dated approach (albeit not uncommon for a codebase that may have started around .NET2.0 and been upgraded over time, without due care and attention); I'm seeing bits that are unnecessary (static TLS-ignoring callback set on every call); I'm seeing bits that make too many assumptions (hope there's no Forms Auth required for that page you're getting the HTML from); but I'm not seeing anywhere where the change to HTTP would outright break stuff.
I can only guess that, not pictured, the app-specific util.getUrl() must return a URL where the HTTPS scheme is hard-coded, but that shouldn't be the biggest change to manage.
So, hokey "compliance" premise is hokey -- sure -- but encrypted parameters rhetoric is misguided (I'm guessing an less-than-stellar attempt to prevent parameter forcing in the PDF downloader, rather than a real attempt to encrypt anything), and the overall result is a dev who, when given a requirement they didn't agree with, did not do the requisite research but felt smart enough to post it on a site dissecting terrible code.
Not sure why I felt the need to defend this particular code -- besides perhaps feeling a kinship towards the original developer taking an approach that looks suspiciously familiar to something I had to dream up (back in 2008). Although I can't say I know a Keith H; nor did we work in cubes or insurance...
(TRWTF is telling me I forgor to check the "I'm not a robot" box, when, in fact, you neglected to show the "I'm not a robot" box, nor any indication that there might be an "I'm not a robot" box. Thanks, Firefox Content Blocker!)
Admin
That's true only though SNI; previously, servers had to send out a certificate which matched any hostname that the browser might be accessing the server on.