Re: RFC 9205 vs. CL0P

I agree that campaigning against this, is beyond the IETF remit. I also agree that the solution does lie within the legal system (sigh). But let's say I want to sue Ipswitch, on the grounds that a lack of institutional knowledge of HTTP is sheer negligence on their part. I certainly have standing... my health insurance is Anthem/Blue Cross, part of their remit is managing my CHP+ as a Colorado resident. But they aren't the ones who compromised my data.



Any halfway competent defense attorney would have a field day, if my only recourse was to convince a jury that the HTTP spec clearly spells out what Ipswitch got stupendously wrong. I might stand a chance (as would a class), if we had a Hemingway-esque BCP document any halfway competent prosecutor could point to, such that the Jury deliberation comes down to a Game of Thrones-esque "It is known" with heads nodding all around the table.



-Eric






---- On Tue, 22 Aug 2023 00:49:32 -0700 Seph Gentle <me@josephg.com> wrote ---



We could. But I doubt it would help.



Frankly, I suspect less than 1% of working software developers have ever actually read any RFC (or BCP) published by the IETF. And the people who read specs aren't the people who need to be told not to run unauthenticated SQL queries on port 80.



I was invited a few times to give guest lectures about computer science at General Assembly. For those who don't know, they run a 3 month "coding bootcamp", where they teach people just enough information about software development to get their foot in the door in the industry. Of their 60 classroom days, 0 of them are devoted to security. Their program seems to teach the philosophy of "If it seems to work, ship it". Needless to say, their students have no idea what the IETF is. They don't read any BCP documnets in their course. And despite writing web software, students graduate without really knowing HTTP.



If you want to stop these ridiculous security vulnerabilities with education, it is those students you need to reach somehow. We could change some of the 9000 or so words in BCP56 to teach some information security. But it won't stop MoveIt from shipping insecure code. If they hired the sort of people who read BCP documents, I doubt they would have made these sort of mistakes in the first place.



For my money, as an industry I think we need to solve this via the legal system. Harm caused by insecure software should be treated the same way that we treat harm caused by negligent builders, or negligent handling of food resulting in food poisoning. There should be much stricter penalties for data breaches like this. And companies shouldn't be able to wish away their liability with a EULA. If data security was an existential risk for companies, you bet security would become an essential part of their product development processes.



But I think campaigning for this isn't part of the IETF's remit. We could change the BCP document, but I doubt it'll stem the tide of sloppy, insecure code.



-Seph




On Tue, 22 Aug 2023, at 2:38 AM, Eric J Bowman wrote:






Ransomware gangs are targeting MFT (Managed File Transfer) software, these days. What makes MoveIt different, is the wide-open front door is HTTP all the way from unauthenticated SQL POST queries on Port 80, to passing "mystery headers" to a webshell. I'm wondering if we can do a better job in the Best Current Practices document, of moving away from spec-speak to more Hemingway-esque (as phk put it) speak. Here's a bunch of boxes to check. If you don't think you need to check one of 'em, here's a deep link into HTTP backing up this best practice.



I appreciate your response and perspective. While I agree the problem is not with HTTP protocol per se, I do believe it's in scope to the WG to attempt to mitigate the sort of naive implementations which have led to the recent theft of all my health and financial records.



-Eric







---- On Sat, 19 Aug 2023 01:33:05 -0700 Willy Tarreau <mailto:w@1wt.eu> wrote ---



Hi Eric, 



On Fri, Aug 18, 2023 at 06:51:46PM -0700, Eric J Bowman wrote: 

> Hundreds more companies and millions more users affected by the MoveIt breach 

> since my last post, which continues to reverberate globally. Yet still, 

> crickets from the HTTP world. Yeah, we're all "experts" at online privacy, 

> but at some point ya gotta share your info with an insurer, hospital, 

> homeowner's association, or whatnot. Even if they aren't using MoveIt, 

> they're probably outsourcing something to someone who does. 

> 

> This isn't me whining about not getting a +1 on updating the best-practices 

> document, I get that I have an abrasive online persona. But I am very 

> disappointed that nobody else in the HTTP world has anything to say about 

> this? I hate being a lone voice in the wilderness, and wonder if I'm the only 

> one free to speak out because my career path has long since diverged from 

> HTTP. Is everyone else in ostrich mode, because their employer/client is 

> breached, or they signed an NDA covering this? Bueller? 



It's not this. It's that I don't see the relation between HTTP and the 

thing you shared. I had never heard about that "moveit" thing, apparently 

it's file transfer software affected by an SQL injection attack, how is 

this any relevant to the HTTP protocol ? 



These days people share lots of data because: 

- they're required to by incompetent and lazy services that pretend 

that it's easier for everyone ("our offices are open tuesdays and 

thursdays from 11:30 to 15:30, but no need to get there in person, 

just send us a copy of your ID card"). 



- they're marginalized as annoying people when they don't want to 

(e.g. try to disable contactless payment on your card in post-covid 

era) 



- tools are incitating to share a lot (how many times a day do I have 

to click on "block" in my browser because it asks me to share my 

location or to record a password for me; how hard is it to add an 

option that says "never ask any the following questions encouraging 

morons to share their whole life online") 



- because it makes them famous and gets them a life. 



It's just human nature and nothing at all related to anything that can 

technically be solved in a communication protocol. 



I know there are idealists who think that security issues are a thing 

of the past that will disappear in the future. History has proven the 

exact opposite, and as frameworks and languages become more and more 

accessible, the need for a certain experience and software culture for 

starting a new project is vanishing, implying that instead the basic 

security issues will become more and more common. So it's a total 

illusion to imagine that we can do something to prevent a data leak in 

software in general. Once the data is stored, it's accessible, either 

by the expected means or by unexpected ones. The rule is: do not share 

what you don't want to leak (which is an important rule for passwords 

by the way). 



But nothing in this discussion concerns HTTP at all. HTTP is just 

one of the many vectors used to access, transfer, steal the private 

information and there's nothing it can do against it because the 

problem is elsewhere. 



Regards, 

Willy