Hacked in a public space? Thanks, HTTPS Have you ever bothered to look at who your browser trusts? The padlock of a HTTPS connection doesn't mean anything if you can't trust the other end of the connection and its upstream signatories. Do you trust CNNIC (China Internet Network Information Centre). What about Turkistan trust or many other “who are they” type …
Any American created communications security protocols and standards should be considered unusable after the Snowden revelations. They are designed with inherent flaws from day one and cannot be trusted.
Enigma in WW2 had (at best) 88 bit security which was broken by maths and mechanical machines in days. Today, some seventy years later, the best we are allowed to use (by US Commerce legislation) is 256 bit. And no one sees this to be an issue.
Snowden only told us what he knew. I'll bet there is a lot he was never given access too. A universal review of all encryption methods needs to be done with the US barred from the room. Think of it like the metric system. The rest of the world can use it and the Yanks can keep their inches.
"A universal review of all encryption methods needs to be done with the US barred from the room."
Trouble is, EVERYONE has the same idea because they're after the same thing: the key to the treasure vault. Fact is, NO government can be fully trusted with this issue since, as other documents have revealed, they're really no better. Which leaves the only alternative which is, unfortunately, anarchy. If you're not under a government's thumb, you're under a bully's thumb. That's life: dominate or be dominated. If you're neither, you've just been overlooked for the moment.
Well, what do you expect from a network designed by pot smoking libertarian hippies paranoid of their government who designed everything while sucking at the DARPA funding tit as they worked for AT&T, et.al.
In their wish for no control, we got an insecure by design but masterfully self-healing interconnection of all the computers in the world and have been applying bandaids and sticking plasters ever since in an attempt to provide security and privacy. Good luck with that!
"In their wish for no control, we got an insecure by design but masterfully self-healing interconnection of all the computers in the world and have been applying bandaids and sticking plasters ever since in an attempt to provide security and privacy. Good luck with that!"
Yep, that's about the size of it. But I'm not sure that it could ever have turned out differently even if anyone had wanted to.
The Internet has two conflicting requirements.
1) Allow people to transfer data, browse and do whatever they want, with no identity check for network access, control or prevention. (this is for the good guys).
2) Stop people transferring data, browsing and doing whatever they want, having established their identity and applying control and prevention (this is for the bad guys).
Contradictory, no?!
Technology fundamentally cannot resolve that contradiction because the Internet cannot distinguish between good guys and bad guys. Only humans can do that, but even then we almost always disagree on who is good and who is bad.
It's made harder because there's really no way of working out who is at the end of an IP address without going round there and knocking on the door. There is no technology we have than can irrefutably establish the identity of the person originating some network traffic. We can get close, passwords, biometrics, etc, but passwords get written or down or lost/stolen, and biometrics are too easily fooled. Short of having some sort of ID chip implanted at birth somewhere where no one would be prepared to have surgery at a later date (another contradiction), there's no irrefutable way of doing it.
And without that there's no way on the network of reliably telling who's who, and without that we're doomed to have a network pretty much like the Internet currently is.
"And without that there's no way on the network of reliably telling who's who, and without that we're doomed to have a network pretty much like the Internet currently is."
In other words, the Internet is going to become a doom zone no matter what because it can either be stateless (and eventually a zone of anarchy) or stateful (and eventually a police state). It's Pick Your Poison with no third option available because "they know you" and "they don't know you" is a strictly binary state.
DARPA didn't invent HTTP or the WWW. One guy at CERN did that.
I'm pretty sure the poster was talking about the underlying protocols (TCP/IP, UDP) whose development indeed was funded by DARPA. Actually ARPA a the time; the net used to be called the ARPANET, and Internet happened when that was opened up to other users besides U.S military, its contractors, and academic institutions.
The great achievement of the "one guy at CERN" was making the data on the internet approachable by the average guy, and in a way that scaled up without central control. And of course making the idea and code available for all for free. Had this been a typical commercial effort, with everything patented, there would have been multiple incompatible and very expensive webs.
I'm pretty sure the poster was talking about the underlying protocols (TCP/IP, UDP) whose development indeed was funded by DARPA. Actually ARPA a the time;
The agency was renamed in 1972, shortly before the first TCP/IP specification was published. So if you want to be completely correct, TCP/IP development was funded by ARPA and then by DARPA.
The great achievement of the "one guy at CERN" was making the data on the internet approachable by the average guy, and in a way that scaled up without central control
Actually, we already pretty much had that. For the first couple of years HTTP and HTML didn't do much that Gopher / Veronica / WAIS / etc didn't also offer. HTTP and HTML succeeded for a few reasons: hypertext had better usability than separate documents and menu-style links; even with character-mode user agents HTML offered some basic presentation markup; HTTP (prior to the barbarism that is HTTP/2) is easy to drive by hand for experimentation and debugging.
Most importantly, though, the time was right. Graphical workstations were becoming common enough (helped by academic efforts like the Andrew Project and Project Athena) that it made sense to create graphical user agents. Not many people had NEXTstations, but quite a few had some sort of X11 box, so NCSA Mosaic (and to a lesser extent other early GUI browsers like Erwise, Spyglass Mosaic, and Viola) became a showpiece for the web. It wasn't much more functional than Gopher+WAIS, but it was prettier.
"I'm pretty sure the poster was talking about the underlying protocols (TCP/IP, UDP) whose development indeed was funded by DARPA."
I'm pretty sure he wasn't (or had no idea what he was talking about) as those underlying protocols have nothing at all to do with any security issues in HTTPS or other protocols used in the WWW.
Besides, HTTPS wasn't invented until later. Early WWW didn't have it. It didn't have any Javascript or Flash either.
You could easily imagine a network where things like authentication and confidentiality are built right into the network itself.
At least this could be applied to the distribution of routing information to prevent things like, say, all traffic to Youtube suddenly going to Pakistan, or any more recent BGP hijacking incident.
"You could easily imagine a network where things like authentication and confidentiality are built right into the network itself."
What would be the point of merging several network layers into one?
Besides, always demanding authentication would probably dilute the value of it.
Ahhh, Snowden, our fav pal whom we want to see come back to the good ole U.S. of A....
You must have meant "what he could steal" rather than "what he knew".... right?
But yes, he could only access so much, even with the borrowed CAC that he borrowed from a mate who should not have loaned it to Snowden (that is, if he loaned and Snowden didn't snatch it).
The traffic is going via the hacker's laptop, since they are masquerading as the router. This means they can establish the HTTPS connection between the user and their laptop. The user sees a secure connection, unaware that the traffic is being decrypted and re-encrypted by the hacker - hence "man in the middle" attack.
It's not that simple.
As someone who deploys MITM for school web filters, the end devices HAVE to trust the root certificate used by the MITM. You can't just pretend to be google.com without the browser throwing a fit. In schools and companies, you do this by distributing your web filter's SSL root certificate into the device's local trusted certs.
Otherwise, Chrome etc. will throw a fit. iPads will stop updating as they detect that the apple.com cert they're using isn't signed by the right authorities. And no genuine CA will issue global wildcard certs (they have been issued for "their own webfilter devices", etc., but they catch an awful lot of flak and there's a massive backlash).
Additionally, modern browsers use certificate pinning and certificate transparency. If the claimed root isn't the one that Google actually bought their certificate from (e.g. Verisign instead of RapidSSL or whatever), the browser will throw a fit again. You will get interception warnings, red bars, and no security.
So the article is wrong, unless people are stupid enough to agree to install random certs into their browser (game over anyway). I have a device in school that intercepts all SSL, decrypts, analyses for keywords, and then SSL's it again to send upstream to website. But you can't do that without a lot of client interaction and basically control of the client machines. You don't have that on just a guest wifi (hence our guest wifi presents security errors for lots of sites, but it's free so what do you want?).
MITM is possible, but doing MITM without the browser detecting the situation is almost impossible these days. And as everything from Google's home page to iPad updates routinely use SSL, you can't just start faking certificates without breaking a lot of things. Hence you have to deploy an iPad "profile" with your webfilter certificate, a similar thing for Android, or put something into certmgr.msc on Windows PC's. Even then, something don't like being subverted, and certain websites "know" they are being intercepted and refuse to secure themselves. Users on such networks just have to live with it, or you have to exclude them from HTTPS decryption.
It's NOT just a matter of sitting in between the connection and pushing even CA-signed fake certs back to someone's browser. You need their device, or their co-operation.
Thanks for clarifying that.
The one nugget of truth in the article is that the list of CAs built in to browsers etc. is ridiculous. I had occasion to look recently. I'll bet at least half of those organizations are corrupt or compromised enough that I wouldn't even trust them to hold my hat - let alone information I actually value. Anybody who wants a signing cert for MITM can surely get one. That really does cast doubt on whether HTTPS is really doing us all that much good, but it's important to understand exactly where the weak link in that chain is.
It's not the list, per se, that's ridiculous. It's the concept: Arbitrary superplustrusty third parties... bestowed omniscience at the whim of myriad equally-arbitrary arbiters?!!!one Marvellous.
Still, how would Finfisher, Prism et al possibly do their thing if our interwebs were actually secure?
B0rken. By design.
I'm not going to disagree with you, there. Centralized trust doesn't work any better than centralized anything else. The only thing I'll say is that the browser makers have made the whole thing even less secure than the design allows by shipping certs for all these shady companies - many of which are clearly just arms of equally shady governments in various forsaken parts of the world. A chain of trust can still be strong if the links are all strong. It's a problem that this becomes hard to guarantee as the chains get longer, but it's also a problem that the browser vendors *knowingly* include weak links in the bags they provide.
The one nugget of truth in the article is that the list of CAs built in to browsers etc. is ridiculous.
Wow, I just checked the list of trusted certificates on my work computer and it's almost 300. There is a scary one from my employer with the two purposes "All issuance policies" and "All application policies".
I remember when the used to be about a dozen trusted certificates and you could recognize the issuer of each, like "Verisign", "Thawte", or "Microsoft". Now, I've got a certificate issued by "TÜBİTAK UEKAE Kök Sertifika Hizmet Sağlayıcısı - Sürüm 3" (sic). Really???
Windows and IE updates regularly add new ones and take old ones away.
Not to mention, everything from banking software to firewall software etc. will add their own.
Although a "this is what you should have" program is probably a good idea, actually it'll be just as much pain to maintain as the root certificate list itself, especially tracing the origin of a cert that someone else has that you don't, etc.
> So the article is wrong, unless people are stupid enough to agree to install random certs into their browser (game over anyway).
Or installs some malware into the machine, or has to install a certificate to connect to a VPN, or ...
> I have a device in school that intercepts all SSL, decrypts, analyses for keywords, and then SSL's it again to send upstream to website. But you can't do that without a lot of client interaction and basically control of the client machines.
So do most corporate networks and almost all corporate PCs are connected to a domain which gives that level of control. In summary if your computer belongs to a domain you can assume that the corporate firewall is decrypting your traffic.
Two things to remember. Never underestimate the power of a stupid voter and just as important, PEBKAC! (Problem Exists Between Keyboard And Chair)
Exactly. If you walked up to the average person sitting in a coffee shop with their laptop and asked them if they had the padlock on the URL bar, most will give you a blank look. They have no clue what it means or do they have a clue what a MitM attack is. I suspect that if the average user did have a clue, they wouldn't use their laptop in the coffee shop. Or, they would be using VPN, etc. Most don't even know the first thing about VPN, like what it means.
Or installs some malware into the machine, or has to install a certificate to connect to a VPN, or ...
None of that is an SSL issue, they''re all trsut compromises.
In summary if your computer belongs to a domain you can assume that the corporate firewall is decrypting your traffic.
This is why I use an invalid certificate on my server - if I *don't* get a warning, I know someone is intercepting my traffic.
Vic.
This is why I use an invalid certificate on my server - if I *don't* get a warning, I know someone is intercepting my traffic.
Devious use of Canary Cert.
However, it would be better if J. Public could script special checks into the browser without extensive knowledge of plugin magic. Just open vi, tap some Lua, and additional checks have been implemented.
HTTPS everywhere and SSL observatory, courtesy of EFF. Always be wary of free wifi - I certainly wouldn't use it unless I was using laptop with a Live CD due to the possibility of malware let alone MITM. Plenty are poorly setup, maintained and secured. Think of using it as being like having unprotected nooky. You may get away with it quite a lot, but then again....
So the article is wrong
The article is very wrong.
Take a look at Moxie Marlinspike's page on sslstrip. It doesn't do anything like what the article claims.
Really, this article is very poorly-researched. You might want to spike it...
Vic.
I understand what a man in the middle attack is but I don't understand why the user's browser would think its receiving data over an ssl connection.
Because there's two separate HTTPS connections: one from the user to MITM and the other from MITM to the real destination. This is exactly how Bluecoat or Cisco recommend deploying their proxies, with an internal SSL CA providing the cover to prevent browser warnings to users.
sslstrip downgrades the connection, but also tries to give enough fake visual feedback to make the user believe the connection is secure. If you're skilled and cautious enough, you may catch it.
If the attacker is able to feed you a fake certificate it could be a little more difficult if you don't check the certificate and its chain. Extended validations one may be a little better, but it all comes down to trust the allowed CAs...
SSLstrip substitutes a fake "padlock" icon for the site's favicon. Crude but effective.
"SSL Inspection" proxies the victim through an actual HTTPS connection, so it's less obvious, but the attacker must install their own root cert on the victim's computer (corporate PC, or via malware, or via dumb PC manufacturers) - unless they've obtained the private key for a "real" root cert...
Somewhat ironically I think it's never been safer to rely on HTTPS. Browsers don't let any old thing pass any more.
Favicons only appear in browser tabs now. If I saw a padlock in my browser tab or HTTP for a HTTPS site like gmail, I would close the tab.
If you want to check the certificate authority you just click on the HTTPS and you get the certificate authority. If it's Turktrust or something strange then something's obviously wrong.
Having a fake MITM on a company laptop is mitigated with Firefox which doesn't use the OS's certificate store.
the attacker must install their own root cert on the victim's computer (corporate PC, or via malware, or via dumb PC manufacturers) - unless they've obtained the private key for a "real" root cert...
It's enough simply to compromise a CA that's trusted by the user agent. You don't need the private key for one of the CA's roots or intermediaries (though that does the job). Get the CA to issue you a certificate for a well-known site, signed by a root/intermediate that's trusted by browsers, and you're home free.
And CAs have been compromised many times - that we know of. And those are just the major ones. Of all those little regional CAs in the browser trust list, how many even have auditing practices sufficient to have a decent chance of knowing whether they've been attacked?
> I don't follow this. Surely if your traffic is being intercepted and redirected to HTTP you don't get the browser padlock?
Yes that's true - but most people are fooled if you simply replace the site's favicon.ico with a padlock image. Plus, browsers don't give any negative security feedback simply because you are accessing a site over HTTP.
The original presentation is worth reading:
http://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf
> In 2016? It's been a few years since browsers were showing the site's icon in the same place as they would show the padlock icon.
Firefox and Chrome, yes. Palemoon still shows a favicon in the url bar - with red/green/blue colors for various levels of HTTPS. Not that the average hacking victim would notice.
Just to be clear: as far as your privacy/security is concerned, HTTPS is worthless.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
