Serious question: if I just run a simple blog with static HTML hosted with Apache, do I really need HTTPS? Will I be penalized by not having it?
And if your answer is "sure, but there will be other websites that are HTTP" my response is "yeah, but one day soon when enough of the web is secure I'm going to disallow all HTTP connections from my browser". And eventually I'll disallow all connections that aren't on HSTS preload lists. And eventually, hopefully, I'll disallow websites that don't have HPKP with long expires.
Many moons ago I was using a proxy engine capable of unpacking/packing HTTPS requests.
It was an in-house proxy taking advantage of Apache and IIS APIs for certificate management and SSL connections.
We used it for debugging secure connections, but I can easily envision other purposes.
Many years have passed since 2000, but I am quite sure it is still quite possible to do it.
These days the only viable way to MITM HTTPS is to either attack the connection while it's in plain text HTTP (ie before the browser redirects to HTTPS:// (which is where the HSTS header comes in to play - it's cached by browsers telling them to default to HTTPS and never attempt a plain text connection) or to form your own HTTPS connection with your own CA signed certificate for the target site. Which would mean you'd either need to compromise a signing authority or have your own CA certs already installed on the victims PC (the latter is what some bad ISPs reportedly do when they inject ads).
Edit: I believe some corporate network proxies also work on the principal of having their own CA certs on their business workstations - so maybe this was how your proxy worked as well?
That information eventually needs to be unpacked, so you get a replicate of the destination site with the same certificates, which you can easily download by pretending to be a browser, but running on your modified server, which then unwraps, repackages and then forwards the request to the original server.
Since one owns the server, it is also relatively easy to disable whatever validations the SSL algorithm requires at library level.
So I don't know TLS and since 2000 I don't mess with this kind of stuff, but I don't think similar approaches aren't possible.
The only way they can succeed in proving who they are, is if their server has access to the corresponding private key of the certificate, which is why you can't spoof a properly secured site unless you either hack their server, crack the encryption, or install your phony certificate on the client (which is what corporations sometimes mandate). That's it.
It's been 17 years since 2000. Whatever security hole you may have used (if any) has long since been patched. The weak cyphers used in some SSL versions which you may have depended on are mostly gone (certainly from high profile targets).
If what you state is true, now in 2017, then there would have to be a huge conspiracy which involves all browser vendors (including Mozilla), as well as all national governments and the EU that hides this fact from the people. All software developers who do catch on (the relevant source code is open source after all) would have to bribed or threatened into silence too.
You are either misinformed or consciously spreading misinformation.
I very much doubt he was even doing anything that clever. Since it was a corporate network he probably just had their corporate CA certificate already built as part of the company machine images / build scripts. He possibly might not even have been aware this was happening if the IT department was large enough that different coworkers managed the desktops from himself.
The "I can't disclose much" argument on a 2 decade old hack is effectively just saying "I can't remember the details" or "I wasn't directly involved in setting up the proxy". Either way, while much has changed in the last 17 years, the practice of some businesses installing their own CA certificates on company assets has been a fairly standard way for corporate proxies to intercept HTTPS traffic. And a great deal less trouble than relying on SSL vulnerabilities since you already own and deploy the destination hardware+software anyway.
Believe me or not, I don't care.
So it's not that I don't believe your anecdote - I'm sure that did happen in some form or other - but the nature of the exploit either isn't how you described or is so old and long since patched that it hasn't been exploitable in more than a decade thus isn't relevant to the statement you were trying to support.
The workaround for that is to create your own SSL certificate for that website (this will create you a public certificate and private key). Which means you will also need that new certificate CA signed otherwise the client (who's own SSL validations you cannot remotely disable like you implied) will give the user a warning about an untrusted certificate (the message will vary from client to client). This means you either need access to the targeted client to install your own CA certs, or you need access to a compromised signing authority.
In short, you can intercept the traffic, but it relies on the client explicitly trusting your certificate. This is the foundation of all security on the web.
We weren't using an off-the-shelf proxy, rather some nice debugging tools with extra help from the networking layering.
Maybe TLS is more full-proof to Website replication with DNS spoofing and a few other tricks, but they did work without issues in SSL 1.0 connections, using modified web servers.
As mentioned this was done with SSL 1.0, I don't know if a similar set of tricks could be done with TLS, as I am out of these type of applications since 2000.
Now believe whatever you want, but I am sure of what I programmed in 2000, the infrastructure we had and gladly explain it in job interviews where confidentiality is assured.
Furthermore TLS 1.0 has been supported since XP but even that is now in the process of being deprecated.
So your attack, if it did depend on SSL v1.0, is so outdated that it's not even worth mentioning. And certainly not in the way that you announced "let me tell you it is quite easy to MITM by any company owning part of the connection."
(Please excuse me using "Windows XP" for approximate timeframes. I can't remember the exact year for when these protocols were phased out but I can remember which devices we had to support).
edit: It was bugging me that I didn't really know much about SSL 1.0 compared with the later protocols so I decided to do a bit of reading. It turns out the reason I don't know much about SSL 1.0 was because it was never publically released[1].
Which makes me even more puzzled about your anecdote as why would you even want to run an SSL 1.0 proxy when even back in the year 2000 no devices were supporting it. Either way it's certainly not proof of the ease of which SSL can be MITMed.
[1] https://en.wikipedia.org/wiki/Transport_Layer_Security#SSL_1...
People who can MITM you when you use HTTP: any entity on e.g. http://www.bgplookingglass.com/list-of-autonomous-system-num...
For this reason I used a VPN while travelling overseas. Most places have wifi of varying quality. To my dismay/horror, I found that Hilton charge EUR15/day for the privelege of using a VPN.
I doubt HPKP will ever see wide adoption. At least not in the form it has now. It's just too damn easy to bork the config and take your entire site offline with no way to remedy that error.
Every website should use HTTPS. It's the right thing to do. It's not hard to do these days.
Unless you use simple tools like GitHub pages. I have a bunch of tiny JS heavy static projects on Pages that I can't easily add HTTPS to.
A current project of mine has some usability issues because it accepts external API requests but I won't allow non HTTPS. It would give me great pleasure to accept all possible APIs, but it's just not right to open users to that risk.
It's not really that hard. Set up auto-renew, make sure the box is up to date and properly firewalled. You won't really have to think much about it.
There are legacy setups like S3 with custom domains, probably github pages with custom domain. But in both cases there is no reason not to be using cloudfront or cloudflare.
I understand that's not technically "your problem", but since you mentioned it, just thought I'd let you know :)
It's unfortunate, because tumblr really is a great blog hosting software and service, if you don't use the social aspects of it.
But these aren't technical limitations! I don't know why Tumblr retricts you from using cloudflare, presumably because they want to control your content.
My two cents, don't use a free hosting service. S3+cloudfront is dirt cheap and will do the trick.
Are you aware of a workaround? Otherwise, I agree with the ease now that LE supports DNS verification. I just wish we could edit existing domains in Gitlab.
I'd rather deal with the very occasional “why not secure?” e-mail rather than pretend my site is actually secure. (I only serve static pages, not forms.)
And regardless of that it offers privacy for your users.
Beyond privacy it also vastly improve security too, since users are most likely to have malware and ads injected by an infected wifi router.
It also increases complexity of an attacker that has control of the local machine, since they'll now have to install a custom root certificate.
Nothing is perfectly safe, all we can do is raise the bar.
My main concern with this happening is that browsers are going to get a reputation for being 'alarmist', so when something really goes wrong, they won't be able to communicate it effectively.
Yes, search engines will penalize you. ISPs will intercept traffic and change it. Your site will load slower. The problems with plain HTTP go on and on.
> all websites with form fields served over HTTP will show a "Not secure" warning to the user
As long as you don't have a form field, you should be fine.