This fine bloatware didn't merely act as an MiTM, it do so so incompetently that it exposed the user to basically any MiTM attack on an SSL connection(the root cert it used to sign bogus certificates was identical across every installation and effectively unprotected and the MiTM component would re-sign any cert handed to it, even an invalid one, opening the user to downright trivial MiTM attacks.
Many "enterprise" (lol) class proxies (deployed by corporations to "protect" their internal networks") do the exact same thing.
There shouldn't be any ability to tamper with the OS so fundamentally and so easily.
Guess what? If you use a windows machine at work, your boss can already install whatever bogus root CA's he wants into your machine without you knowing it, via GP. And he'll claim he has to, because w/o it, the corporate proxy can't MITM you.
That is a feature, not a bug. The whole point to Windows GP is to allow your boss to push bogus root CAs into your work machines' store (without you knowing it, let alone preventing it) so the corp proxy can MITM sniff all of your https traffic at will. Remove that ability, and expect your local PHB to whine incessantly.
Never mind that the idiots running the IT dept have no clue how bad it is to deploy a CA that can automatically sign forged certs arbitrarily. And most employees are clueless enough to never bother checking their trust root CA list.
Unrestricted MS group policy push means all of TLS/SSL is a complete sham.
Hopefully this Superfish fiasco will bring this to light, However, I am not optimistic, given the quality of reporting on it so far, and the fact that employers do not want their employees to know exactly how much the corporate proxy has compromised the entirety of internet security.
I know the response is "well just trust your IT dept, they won't let their bogus root CA priv key fall into the wrong hands; corporate proxies are for your own good".
Corrupting a Windows machine's CA store is very common in "enterprise" environments where your employer wishes to proxy all outgoing SSL/TLS connections.
The fact that most people are completely unaware of this is disturbing, but unsurprising.
Again, why would you use the host key for this purpose? Most likely the client would generate the key (no relation to the host key) they would want preloaded. The manufacturer has no reason to use the host key as both a host key AND a key in the authorized_key file. That is simply stupid.
No, in this case, knowing the host key would let you pose as the host.
Then again, you don't even generally need the host key to post as the host because 9 times out of 10 nobody actually verifies that the presented host key matches the expected host key.
If the host is unknown, generally they simply assume the key is correct. If the last stored key and doesn't match the one presented, they generally ignore the error that ssh spews telling you of a potential MITM attack.
The host key pairs are NOT used to authenticate the incoming user.
They're used to prevent MITM attacks (by uniquely identifying the endpoint), so this statement
"It’s hard to say if the key errors means that a remote attacker could log into all of the devices, as it would depend on how the routers are configured for remote authentication."
It's complete bull; the article is written by a clueless moron.
Attackers would have to use the keypairs to setup MITM attacks for EVERY machine they wish to compromise.
Revision controlling machine generated xml (or any other machine generated code) with the assumption that it is human readable (because of the format) is a bad idea, just like keeping compiled binaries under revision control is a bad idea. It is just as non-human readable.
You want to keep the actual human generated source under revision control... which you obviously can't do for any document generated by a GUI.
Sure, you can use revision control to simply keep a history of versions, but that doesn't do anything for any of the multitudes of other reasons to use a RCS.... hell, you can keep a history by just timestamping every revision of file in their filenames.
Unless they can be bothered to learn something like docbook, they deserve any and all pain arising from the drawbacks of whatever idiotic workflow their uninformed, incompetent, clueless PHB imposes on them.
Why doesn't the summary mention to look for/bin/iptable6?
Wouldn't that be the single most important piece of information to convay? Oh. No. The single most important piece of information seems to be to plug some AV garbage.
Slashdot Mirror
The OP assumes religious beliefs is emotional and irrational. That's false. Discussion over.
Agreed, religious beliefs are emotional and irrational.
Nobody should worship anybody based on faith.
It all started with corporate "enterprise" firewall vendors who saw a demand for MiTM-in-a-box from "enterprise" IT.
Corporations are notoriously uninterested in the repercussions of their actions.
This fine bloatware didn't merely act as an MiTM, it do so so incompetently that it exposed the user to basically any MiTM attack on an SSL connection(the root cert it used to sign bogus certificates was identical across every installation and effectively unprotected and the MiTM component would re-sign any cert handed to it, even an invalid one, opening the user to downright trivial MiTM attacks.
Many "enterprise" (lol) class proxies (deployed by corporations to "protect" their internal networks") do the exact same thing.
Allowing unrestricted remote access to your machine's trusted root CA list via GP is a feature of windows.
Why would they remove it? It is for the "enterprise".
There shouldn't be any ability to tamper with the OS so fundamentally and so easily.
Guess what? If you use a windows machine at work, your boss can already install whatever bogus root CA's he wants into your machine without you knowing it, via GP. And he'll claim he has to, because w/o it, the corporate proxy can't MITM you.
That is a feature, not a bug. The whole point to Windows GP is to allow your boss to push bogus root CAs into your work machines' store (without you knowing it, let alone preventing it) so the corp proxy can MITM sniff all of your https traffic at will. Remove that ability, and expect your local PHB to whine incessantly.
Never mind that the idiots running the IT dept have no clue how bad it is to deploy a CA that can automatically sign forged certs arbitrarily. And most employees are clueless enough to never bother checking their trust root CA list.
Unrestricted MS group policy push means all of TLS/SSL is a complete sham.
Hopefully this Superfish fiasco will bring this to light, However, I am not optimistic, given the quality of reporting on it so far, and the fact that employers do not want their employees to know exactly how much the corporate proxy has compromised the entirety of internet security.
I know the response is "well just trust your IT dept, they won't let their bogus root CA priv key fall into the wrong hands; corporate proxies are for your own good".
Right.
Why doesn't windows defender alert you when your employer pushes their proxy's CA into your work machine's trusted CA list via group policy push?
Superfish is just the tip of the iceberg.
Corrupting a Windows machine's CA store is very common in "enterprise" environments where your employer wishes to proxy all outgoing SSL/TLS connections.
The fact that most people are completely unaware of this is disturbing, but unsurprising.
Again, why would you use the host key for this purpose? Most likely the client would generate the key (no relation to the host key) they would want preloaded. The manufacturer has no reason to use the host key as both a host key AND a key in the authorized_key file. That is simply stupid.
No, in this case, knowing the host key would let you pose as the host.
Then again, you don't even generally need the host key to post as the host because 9 times out of 10 nobody actually verifies that the presented host key matches the expected host key.
If the host is unknown, generally they simply assume the key is correct.
If the last stored key and doesn't match the one presented, they generally ignore the error that ssh spews telling you of a potential MITM attack.
Why in the world would you add a device's public host key to the authorized key file?
The host key pairs are NOT used to authenticate the incoming user.
They're used to prevent MITM attacks (by uniquely identifying the endpoint), so this statement
"It’s hard to say if the key errors means that a remote attacker could log into all of the devices, as it would depend on how the routers are configured for remote authentication."
It's complete bull; the article is written by a clueless moron.
Attackers would have to use the keypairs to setup MITM attacks for EVERY machine they wish to compromise.
Revision controlling machine generated xml (or any other machine generated code) with the assumption that it is human readable (because of the format) is a bad idea, just like keeping compiled binaries under revision control is a bad idea. It is just as non-human readable.
You want to keep the actual human generated source under revision control... which you obviously can't do for any document generated by a GUI.
Sure, you can use revision control to simply keep a history of versions, but that doesn't do anything for any of the multitudes of other reasons to use a RCS.... hell, you can keep a history by just timestamping every revision of file in their filenames.
Unless they can be bothered to learn something like docbook, they deserve any and all pain arising from the drawbacks of whatever idiotic workflow their uninformed, incompetent, clueless PHB imposes on them.
How about something simple then?
3-way merge? Interactive merge?
And that can be tied in to svn or git hooks w/o a windows machine?
All the more reason not to use opaque binary formats at all.
That functionality belongs in the revision control system, not hidden away in some app someplace.
LOL @ binary formats and revision control.
Why doesn't the summary mention to look for /bin/iptable6?
Wouldn't that be the single most important piece of information to convay? Oh. No. The single most important piece of information seems to be to plug some AV garbage.
How about IMAP support that doesn't completely suck?
o365 is such a huge POS.
I'm not sure you know what rent-seeking is.
Has any law enforcement agency ever maintained that they need a warrant for anything?
Don't forget avahi, which reliably causes shutdown to take o^n time (vs number of network interfaces and ipaliases) to shut down