This is the original article. Note that it is from 2013.
tal
joined 2 years ago
I mean, I'm serious. Like, it's a big CRM platform that people use and I understand has an ecosystem of software that integrates with it, is well-established.
It's like, someone may not like Photoshop. Frankly, I avoided it in favor of Gimp since the early 2000s, and I really don't like the fact that it's SaaS now.
But you can't just say "Photoshop sucks, artists use charcoal sticks now". You have to have that alternative, like Gimp. And even then, people are going to have some loss in experience and loss in integrated software (like plugins and stuff) in a switch.
I don't do CRM. But my understanding is that it does matter and that that ecosystem matters, and "just throw one's hands up in the air and tell people not to use a CRM platform" is probably not going to fly.
kagis
I thought that SugarCRM was open-source, but it looks like I'm a decade out-of-date
it started as an open-source project, but apparently the company founded around it took it proprietary. And I bet that it doesn't compare in size in terms of people with experience with it or software that integrates with it.
kagis
https://www.salesforceben.com/salesforce-ecosystem/
The Salesforce ecosystem is an absolute behemoth. Salesforce employs around 70,000 people and is the biggest employer in Silicon Valley. They also have a market cap of a quarter of a trillion – pretty impressive, right?
However, when you look at the Salesforce ecosystem, there are 15M people involved in Salesforce’s community who work as end users, in consultancies, and for app companies. The Salesforce economy is also predicted to generate revenues of six times that of Salesforce by 2026.
Like, you're not gonna move that overnight.
It could be that Salesforce sucks on a technical level as a platform. I don't know, haven't used it. But what I'm saying is that I suspect that for a lot of users, they aren't in a great position to plop in an existing replacement overnight.
EDIT: It sounds like there's a continuing open-source fork of SugarCRM, SuiteCRM. This is the first I've heard of it, though, so I kinda suspect that the userbase isn't massive.
Is there a comparable CRM alternative?
For cords, IIRC you can make them taste bad.
hits Amazon
https://www.amazon.com/Cord-Protector-CritterCord-Protect-Hazardous/dp/B000EH2I5O
Maybe it'd be possible to make something similar for phone cases.
keep portable charging devices out of pets' reach
Realistically, I suspect that a smartphone battery is enough to start a fire. I doubt that there is any chance that every dog owner is going to keep smartphones out of pet reach.
I have, in the past, kind of wished that settings and characters could not be copyrighted. I realize that there's work that goes into creating each, but I think that we could still live in a world where those weren't protected and interesting stuff still gets created. If that were to happen, then I agree, it'd be necessary to make it very clear who created what, since the setting and characters alone wouldn't uniquely identify the source.
Like, there are things like Greek mythology or the Robin Hood collection of stories, very important works of art from our past, that were created by many different unaffiliated people. They just couldn't be created today with our modern stories, because the settings and characters would be copyrighted and most rightsholders don't just offer a blanket grant of rights to use them.
That's actually one unusual and notable thing H.P. Lovecraft did
if you've ever seen stuff in the Cthulhu Mythos, that's him. He encouraged anyone who wanted to do so to create stuff using his universe. One reason why we have that kind of collection of Lovecraftian stuff.
But you can't do that with, say, Star Wars or a lot of other beloved settings.
Nintendo shouldn’t be able to patent game mechanics
Those are patents, not copyrights. There are a bunch of different forms of intellectual property. Off the top of my head:
-
Copyright
-
Trademark
-
Patent
-
Moral (not very substantial in the US, but more-meaningful in France)
There is a class of products that consist of a hardware box that you ram your network traffic moving between different business locations in a company through that tries to accelerate this traffic. F5 is one manufacturer of them. One technique these use is to have private key material such that they can pretend to be the server at the other end of a TLS connection
that's most of the "encrypted" traffic that you see on the Internet. If you go to an "https" URL in your Web browser, you're talking TLS, using an encrypted connection. They can then decode the traffic and use various caching and other modification techniques on the decoded information to reduce the amount of traffic moving across the link and to reduce effective latency, avoid transferring duplicate information, etc. Once upon a time, when there was a lot less encrypted traffic in the world, you could just do this by working on cleartext data, but over time, network traffic have increasingly become encrypted. Many such techniques become impossible with encrypted traffic. So they have to be able to break the encryption on the traffic, to get at the cleartext material.
The problem is that to let this box impersonate such a server so that it can get at the unencrypted traffic, they have to have a private key that permits them to impersonate the real server. Having access to this key is also interesting to an attacker, because it would similarly let them impersonate the real server, which would let them view or modify network traffic in transit. If one could push new, malicious software up to control these boxes, one could steal these keys, which would be of interest to attackers in attacking other systems.
It sounds, to my brief skim, like attackers got control of the portion of F5's internal network that is involved with building and distributing software updates to these boxes.
The problem is that if you're a sysadmin at, say, General Dynamics (an American defense contractor which, from a quick search, apparently uses these products from F5), you may have properly secured your servers internal to the company in all ways...but then the network admin basically let another box, which wasn't properly secured, into the encrypted communications between your inter-office servers on the network. It could extract information from your encrypted communication streams, or modify it. God only knows what important data you've been shoveling across those connections, or what you've done with information that you trusted to remain unmodified while crossing such a connection. It's be a useful tool for an attacker to stick all sorts of new holes into customer networks that are harder to root out.
It definitely is bad, but it may not be as bad as I thought above.
It sounds like they might actually just be relying on certificates pre-issued by a (secured) CA for specific hosts to MITM Web traffic to specific hosts, and they might not be able to MITM all TLS traffic, across-the-board (i.e. their appliance doesn't get access to the internal CA's private key). Not sure whether that's the case
that's just from a brief skim
and I'm not gonna come up to speed on their whole system for this comment, but if that's the case, then you'd still be able to attack probably a lot of traffic going to theoretically-secured internal servers if you manage to get into a customer network and able to see traffic (which compromising the F5 software updates would also potentially permit for, unfortunately) but hopefully you wouldn't be able to hit, say, their VPN traffic.
F5 said a “sophisticated” threat group working for an undisclosed nation-state government had surreptitiously and persistently dwelled in its network over a “long-term.” Security researchers who have responded to similar intrusions in the past took the language to mean the hackers were inside the F5 network for years.
This could be really bad. F5 produces WAN accelerators, and one feature that those can have is to have X.509 self-signed certificates used by corporate internal CAs stored on them
things that normally, you'd keep pretty damned secure
to basically "legitimately" perform MITM attacks on traffic internal to corporate networks as part of their normal mode of operation.
Like, if an attacker could compromise F5 Networks and get a malicious software update pushed out to WAN accelerators in the field to exfiltrate critical private keys from companies, that could be bad. You could probably potentially MITM their corporate VPNs. If you get inside a customer's network, it'd probably let you get by a lot of their internal security.
kagis
Yeah, it sounds like that is exactly what they hit. The "BIG-IP" stuff apparently does this:
During that time, F5 said, the hackers took control of the network segment the company uses to create and distribute updates for BIG IP, a line of server appliances that F5 says is used by 48 of the world’s top 50 corporations
MyF5 Home > Knowledge Centers > BIG-IP LTM > BIG-IP Local Traffic Manager: Implementations > Managing Client and Server HTTPS Traffic using a Self-signed Certificate
One of the ways to configure the BIG-IP system to manage SSL traffic is to enable both client-side and server-side SSL termination:
- Client-side SSL termination makes it possible for the system to decrypt client requests before sending them on to a server, and encrypt server responses before sending them back to the client. This ensures that client-side HTTPS traffic is encrypted. In this case, you need to install only one SSL key/certificate pair on the BIG-IP system.
- Server-side SSL termination makes it possible for the system to decrypt and then re-encrypt client requests before sending them on to a server. Server-side SSL termination also decrypts server responses and then re-encrypts them before sending them back to the client. This ensures security for both client- and server-side HTTPS traffic. In this case, you need to install two SSL key/certificate pairs on the BIG-IP system. The system uses the first certificate/key pair to authenticate the client, and uses the second pair to request authentication from the server.
This implementation uses a self-signed certificate to authenticate HTTPS traffic.
Well. That...definitely sucks.
For example, its not only illegal for someone to make and sell known illegal drugs, but its additionally illegal to make or sell anything that is not the specifically illegal drug but is analogous to it in terms of effect (and especially facets of chemical structure)
Hmm. I'm not familiar with that as a legal doctrine.
kagis
At least in the US
and this may not be the case everywhere
it sounds like there's a law that produces this, rather than a doctrine. So I don't think that there's a general legal doctrine that would automatically apply here.
https://en.wikipedia.org/wiki/Federal_Analogue_Act
The Federal Analogue Act, 21 U.S.C. § 813, is a section of the United States Controlled Substances Act passed in 1986 which allows any chemical "substantially similar" to a controlled substance listed in Schedule I or II to be treated as if it were listed in Schedule I, but only if intended for human consumption. These similar substances are often called designer drugs. The law's broad reach has been used to successfully prosecute possession of chemicals openly sold as dietary supplements and naturally contained in foods (e.g., the possession of phenethylamine, a compound found in chocolate, has been successfully prosecuted based on its "substantial similarity" to the controlled substance methamphetamine).[1] The law's constitutionality has been questioned by now Supreme Court Justice Neil Gorsuch[2] on the basis of Vagueness doctrine.
But I guess that it might be possible to pass a similar such law for copyright, though.
https://en.wikipedia.org/wiki/N%2B%2B
https://en.wikipedia.org/wiki/N%2B
https://en.wikipedia.org/wiki/N_(video_game)