Does HTTPS actually protect your data?

[IanMacdonald]

Been doing a bit of research into this, and the results are just slightly worrying.

https://iwrconsultancy.co.uk/blog/https

It strikes me that the security researchers who've put videos on YT about this, have been 'cherry picking' scenarios where SSL does protect. Which it does in some cases. It's the number of instances where it doesn't that are the concern though. Especially as people will tend to assume that they are always protected from password theft if it is active. 

[grumpydoc]

Implemented correctly it protects data "in flight" so, for example, a malicious employee at your ISP could not sniff all traffic to pull out user name/site/password combos.

I suppose its value depends on how much of a threat you think the above is compared with, say, exploiting poor programming and sanitising of user input to suck all of the user name/password combos from the remote database.

It also prevents ISPs modifying data in transit in other ways such as inserting ads - so I suppose it does have its uses.

[hermit]

It's better than nothing but you have full time criminals looking for ways around it. Do you keep all of your money under your mattress because sometimes banks get robbed?   Lots of compromises still happen because people click on links or open attachments they shouldn't.  Sure, someone just mistakenly picked you out for a huge refund you don't have coming.  Just click on the attachment to claim it....... 

[Red Squirrel]

The way I like to see encryption is that it does not stop eavesdropping 100%, but it slows it down. The big 5 eyes networks store every packet that crosses their listening posts, if they can't decrypt it with today's tech they will be able to with tomorrow's, but they may also have discard the data by then if they feel it's not important to them or them finding out the info may not be as critical by then.

[tggzzz]

Been doing a bit of research into this, and the results are just slightly worrying.

https://iwrconsultancy.co.uk/blog/https

It strikes me that the security researchers who've put videos on YT about this, have been 'cherry picking' scenarios where SSL does protect. Which it does in some cases. It's the number of instances where it doesn't that are the concern though. Especially as people will tend to assume that they are always protected from password theft if it is active.

It protects in the same way as an armoured van protects its contents during the journey from here to there. If the employees are crooked or the buildings are tin shacks, the value of an armoured van is moot.

[T3sl4co1l]

Is it enough, on its own?  No, of course not.

Is it better than nothing?  Absolutely!

I even set up HTTPS on my website (even though I have no active content there..).  Was kind of a pain, but it's behaving well enough.  I use Let's Encrypt's certification.

Tim

[Jr460]

The biggest problem with HTTPS is that until recently and still by default it will try to use some very poor encryption. 

Many places have polices and scan their network to find web servers that will accept poor ciphers. 

New browsers will also disable weak ciphers.

The other problem is the key management for the negotiated cipher.   It is sent over the connect encrypted by private key of the server's certificate.  So like other have said, if you record all traffic, and then later get the certificate either hook/crook, poor management of the web server, or FBI with a national security letter, then all past traffic can be decrypted.

Much new versions of TLS/SSL allow for Diffie-Hellman key negotiation where the key is never sent over the wire.  This is what SSH has done since day one.   It doesn't matter if you record the traffic, the keying material is never sent or kept.

Now, try to find web servers that only use DH for keys.....   I don't think it is very popular at this time.

[chriswebb]

One way to test your HTTP server is to use something like the ssl lab's tester:

https://www.ssllabs.com/ssltest/

Gives you a pretty detailed look at what your server does, and if it is doing something poor, it gives great details on how to fix.  Went from a D to an A+ in a few minutes with that site.

[bd139]

Let’s just add that it’s a cat and mouse game. Protocols are evolving. Ciphers are evolving. Key exchange methods are evolving. People are finding viable attacks against these bits of mathematics all the time.

Fundamentally TLS is secure but only if you configure it properly and keep on top of protocol evolution.

There is a possibility that the cat will catch up with the mouse suddenly. At this point we’re shit out of luck and society may fall overnight. No joke.

In the mean time it all stacks on honesty of the PKI which is debatable, whether or not implementations are flawed or have been made flawed by security service operators (look at openbsd IPSec for an example of this) and whether or not either peer is trustworthy. If you’re using an old TLS version to talk to Equifax from a crapware infested shitbox then it’s game over.

Ugh it’s a mess.

SSH is much better when it comes to key management.

(This is the day job by the way)

[taydin]

https is a good defense against individual or organized crooks, or government agencies of less developed countries. But I am assuming that it is absolutely zero defense against cryptoanalysis by the NSA and related organizations. So, is it safe or not for YOU? Well, it depends on how critical your secret is

[lundmar]

Once we get powerful quantum computers all current ciphers will be breakable and no archived data from the past will be secure. It will be a game changer.

My point is, whatever you do, don't use the internet until we have post-quantum cryptography!

Best to play it safe - I'll see you guys again in 2030.

[IanMacdonald]

Some of the responders seem to have missed the point. It's not a question of whether the SSL cipher is strong or weak, or whether it is better than nothing. It's a very simple issue of whether the product does what it says on the tin. It is supposed to prevent a MITM from stealing sensitive data such as passwords. If it does not do that to a reasonable degree, then it is snake oil.

Your call as to what a reasonable degree is, but I'd have said that over 75% success rate might qualify, under 50% not. After all you don't expect AV software to trap every virus, or a spamfilter every spam. You expect a serviceable performance, though. Especially if you have to pay for the product. Which you do, where proper certificates are concerned.

The lowdown is:

HTTPS prevents your ISP from acting as a MITM. Success.

HTTPS does not prevent third party advertisers from acting as a MITM. Fail.

Each visit to a large website involves one ISP, but anything up to 40 connections to advertisers and other third parties.

That is a 2.5% success rate in performing its claimed function. Give or take.   

Even with just one advertiser on a page, that's still only a 50% success rate.

There is no way, but no way, that a product with a 2.5% success rate can be considered fit for purpose.

If anyone can challenge these findings with a demo proving that adsites cannot read passwords typed anywhere in the host page, then by all means show me. With the complexity of these subjects I realise that it's easy to be wrong. However, I've been quite thorough in researching this. 

[Ash]

Hi Ian,

I've been developing web applications since the mid 90's (yes, the very beginning). I think there are a number of problems with your argument which basically come from a lack of experience with this stuff. This is a complex topic, and I will only give simple answers below, if you want to develop a web site, it is your responsibility to learn this in depth (or employ someone that has) - and honestly most people get it wrong at least a few times. The developer must work with the tools the browsers supply to ensure security.

Internet security is built on a number of layers, TLS (the encryption behind HTTPS) is only one on them, the browser implements many layers of defence in depth that I think you should go and read about. Basically it is all layers of trust, starting at the user deciding to visit your site and trusting you, the developer/owner, that you are doing things properly. And yes, this means that it is easy to have untrustworthy sites - protect yourself with knowledge; but without this web of trust, the Internet wouldn't exist, period.

TLS / HTTPS has exactly 2 jobs. Authentication of the Server to the Client browser (it is possible to also authenticate the client to the server, but this is almost never done), and ensuring the data over the wire is secure and tamper proof. That's it. nothing more.

Yes, older cipher suites are now considered insecure and are deprecated in any good browser. This is normal and was built into the negotiation process from the beginning. Also look at certificate pinning where it is possible to detect that a certificate has been substituted (this can be done in a corporate environment for instance where a new root authority can be created).

I believe you are miss-understanding the same-origin-policy.

This is enforced very rigorously by the browser at the DOCUMENT level - that is a HTML document that you load. The supposed MITM attach you demonstrate is invalid - you, as the site developer - have SPECIFICALLY GRANTED TRUST to your supposed evil site by including it into the document. This is EXACTLY how the web is supposed to work, it is a very useful and powerful thing. But as you demonstrated - if you aren't careful (as a site developer), you will get pwned, often..

If you don't trust a site, you MUST NOT include any resources from it, especially scripts because once you do that script is considered part of your document because you have explicitly trusted it  (by writing the script tag).

If you DON'T trust the site, but you still want to use the "content" they offer (eg Ads) you must IFRAME it into your site. This creates a brand new document  / security scope with the same-origin-policy set up for their domain. Your document tells the browser where to place that document, and that is it. There is no way that iframe document (excluding browser bugs, and some very carefully designed message passing schemes that require cooperation between both ends) can access information in your document.

To address issues you raised on your article about HTTPS "failing" to protect a password at the ends - yes, correct it doesn't. Given its role, it makes absolutely no sense to assume that it would.

Protecting passwords is your job as a developer. Hint - NEVER EVER EVER store passwords or simple hashes of passwords anywhere. The incoming password should immediately be securely hashed (https://crackstation.net/hashing-security.htm) and securely erased from memory before using this hash to verify identity and issuing a session level identity token. Read about OAuth for instance. If done at scale the "normal" web site doesn't handle passwords at all, only tokens, a separate very carefully audited and protected site manages the user authentication process. Basically these tokens are stored as cookies with various settings to ensure they are only ever sent over encrypted connections to a specific host (or domain related to the host) - the site works with the tools the browser supplies to ensure this token which represents your identity can't be compromised.

I should also point out to those reading this, that you shouldn't trust ANY web site too much. Get a secure password manager (I use KeePass, but there are others) and have a different large randomly generated password for each web site. Protect this with a long, strong password in your password manager - a long phrase or sentence is a good start. This way when the inevitable security breach occurs (because developers are people and make mistakes) it is just that one site that is compromised.

For instance, I've dealt with local service company that is clearly storing plain text passwords, and even better presenting these passwords to their support people - I've been on the phone to one and the lady commented "oh, wow, that's a weird password" when she opened my profile.. (it was a large random string) WTF.. that is why I use password managers.

Hope that help clarify the issues, not start a flame war. 

I'm happy to discuss the specifics, but it probably doesn't belong on EEVBlog..

Actually, if anyone here develops embedded stuff with web sites maybe it does.. These are often insecure (wifi routers, I'm looking at you) 

Ash.

[IanMacdonald]

Well then, Ash, I've been programming longer than you. I've also written programs in industry. You need to see this from the end user's perspective.

The end user is not expected to understand every line of the code. The end user does have a right to expect that the code will do what is claimed of it.

This also extends to situations where a software product could work under some circumstances, but is being promoted for use in circumstances where it will self-evidently not achieve its goals.

A promotional drive is in effect, to force all websites to use HTTPS. The same promoters are advising webmasters NOT to use alternatives such as client side password hashing, because (they say) such approaches are inferior to SSL.

This places a degree of product liability on the promoters. It requires that HTTPS should protect passwords on ALL websites. I emphasis the all.

If webmasters were left to decide whether the product is suitable for any given role, that would be a different legal situation. They are not.

I have demonstrated that it is ineffective in protecting passwords on sites with third party advertising.

The end user is meanwhile told by the browser that SSL is doing the job of:

1: Authenticating where (all of) the data comes from
2: Preventing MITM attacks.

I have demonstrated that on sites with ads, it does neither.

I can tell you from experience of advising on such cases  that legal counsel take a pragmatic view of such matters. They are not interested in 'Ah but you don't have the knowledge to see why the product couldn't actually be expected to do that, even though our promotional material says that it does.' They are only interested in the broad nature of the claim made, and whether the product does the basic job it is sold for.

[Ash]

Ian,

You certainly have not demonstrated that it is possible to MITM https, or that sites with ads must expose credentials or other details to the advertisers.

You have demonstrated that it is possible for people to design terribly insecure web sites, especially if they include code from 3rd party sites. You have also demonstrated that sites are able to collude with evil 3rd parties to expose your personal information.

This is not the fault of the tool, this is the fault of the owner of the site, the content producer. If you turn off https, your "attack" still works.

Your argument is very much like blaming:
 - an MP4 video codec if the video contains miss-information or lies.
 - a telephone if a phone scammer convinces you to part with money over the phone

It isn't the protocol, it is the content producer that is at fault.

The drive to get people to use https on all their web sites is good and important:

People should not send any credentials or personal information to a non-https web site.

If it is sent in the clear, anyone can read it on the network. You claim that this doesn't happen often, I'd say it just doesn't make the news because it isn't normally a company to "blame", just some poor person having their identity or credit cards details stolen because they used the free open wifi at the local shopping mall..

You simply can not implement a secure site asking for any personal information or credentials with out encryption over the link. This is what the drive to https is about - ensuring that users KNOW not to send personal information to a insecure web site.

If you own a web site that isn't just static text, sorry but tough. Get a certificate and implement https. In fact, enforce https only so that the user is redirected properly to https before interacting with the site (and also ensure all cookies are https only).

Is it still possible to attack a web site with https, yes (Security is hard). Does that make https or the drive to move everything to https wrong. no.

Your proposal to provide a "hash this input value" in the browser could mask the actual password text sure, but what about my name, date of birth, address, email address that a site asks for? It can't help with that. What about the information leaking about what articles I read, or interests I have, or comments I made?

But there are a big problems with client side hashing - it simply does not fix the issue. This is the same if it is done in Javascript or in the browser code itself (your augmented input box). (BTW: doing it in Javascript is a terrible idea, for even more reasons than below).

How do I prevent someone reading the hash as it goes over the wire/air? Then simply using it again (replay attack)?

For it to work, it must always hash to the same thing so I can check it against my database. The hash is now effectively my password (I don't need the original text, just the hash to sign in), and unless you are using https, you just let anyone sign in as me. Back to square 1. And even worse, now my database contains hashes that can be directly used to sign into the site so if that data is compromised it is again all over.

What about the next request? The browser has to either send the hash again, or the server issues you with a session token of some kind. What is to stop someone again on the same network catching that session token and again, replaying it.

No encryption means there is no possibility of security. This is what these campaigns are trying to teach people.

Ash.

[IanMacdonald]

I have demonstrated that it is possible to MITM HTTPS.  I have done so, using two HTTPS sources. Also that it is trivially easy to do so. Jawdroppingly easy. I suspected such for a while, but hadn't gotten round to testing it out. 

There may be ways of mitigating the attack, and it is possible that sites with advertising are employing them. The issue here is, how do you tell if any given site is using them? If a given site is NOT, then it is not safe to log in at that site. However, you have no way of determining that.

Which really puts us back to square one, that we don't know if any given site is safe. 

Regardless of that, it is unacceptable for a browser to be claiming that all page content came from an authenticated source, when that is patently untrue.

The 'Hash becomes the password' rebuttal is one which crops-up in numerous places. It seems to be in the nature of a 'canned response' the promoters of HTTPS have advised their supporters to use. It is BS. Hashes are normally salted They do not become the password.   

We *KNOW* that passwords get stolen from Web and database servers, and in vast numbers. That, is an incontrovertible fact.  Meanwhile, as a justification for the HTTPS rollout it is surmised that passwords are being stolen by ISPs, purely because that is technically possible. Being possible, however, does not mean it is taking place. 

For that matter, my ISP is theoretically able to debit any amount they want from my bank card. Being possible, does not of course mean that they do. However, applying the HTTPS argument would require that some way of preventing this activity MUST be implemented, purely on the basis of it being a theoretical risk. I don't see that happening. Why not?

Likewise there is nothing to stop my neighbour from picking up her kitchen knife, coming round here and killing me with it. The theoretical possibility exists, bur I do not regard the probability of that happening as being sufficient to demand any special security measures. If we start trying to cover every possible theoretical risk, the situation soon gets out of hand.

On the other hand I have a dashcam because I know there is a documented risk of fraudulent insurance claims, road rage incidents and so on. The risk I am covering is not theoretical.

The pragmatist in me says that all this time and money spent on HTTPS is time and money wasted that should be spent on fixing documented security issues. Rather than hypothetical ones.

[madires]

A lot of "security" appliances perform SSL/TLS MITM to ensure compliance, to prevent leakage of business secrets or to perform malware scanning. That's also the reason why TLS 1.3 is delayed. Those boxes simply block TLS 1.3 while the IETF working group tries to keep the improved security in 1.3. A fallback option to 1.2 would render the security benefits of 1.3 useless.

[IanMacdonald]

This is true, and I believe that was the issue behind the Lenovo/Superfish scandal.

Which just got me thinking: If a proxy of some kind sets up a SSL relay on the main site, that would be apparent to the end user because the 'padlock'  info would show the proxy's cert, not that of the visited site. So, easy to detect. However, if it proxied some or all advertising connections but was careful not to touch the main site's data stream, would the user be aware of that? Probably not, because the browser doesn't display the certs for adsites.

If so, then there is nothing  to stop your ISP  from selectively proxying known advertising connections, for example doubleclick. You won't know that the ads are being relayed to you under your ISP's cert instead of the adsite's cert. The proxied ads could be a vehicle for various kinds of MITM nastiness.

In which case, if the purpose is to stop your ISP from snooping, then that protection is very easily circumvented. 

Which would underline that the only dependably secure HTTPS connection is a single origin one.

[rich]

I have demonstrated that it is possible to MITM HTTPS.  I have done so, using two HTTPS sources. Also that it is trivially easy to do so. Jawdroppingly easy. I suspected such for a while, but hadn't gotten round to testing it out. 

No, as Ash has already stated, you've only demonstrated that a page which embeds script served from a 3rd-party is vulnerable to attack from that 3rd-party script - Either directly by the 3rd party script or by being compromised and serving up a rouge script. This isn't news.
 

There may be ways of mitigating the attack, and it is possible that sites with advertising are employing them. The issue here is, how do you tell if any given site is using them? If a given site is NOT, then it is not safe to log in at that site. However, you have no way of determining that.

Which really puts us back to square one, that we don't know if any given site is safe. 

You don't. Even if the site didn't (or was prohibited) from loading 3rd party scripts you still don't know if it is 'safe'. If you really want to know how secure the client portion of a site is, you'll need to security review/test it for your given definition of 'safe'. But, as users, we don't do that because life is too short. Instead we form a trust relationship with the original vendor. But how do you know whether the page you're viewing is the real site or an imposter (either because MITM or DNS attack)? Perhaps if there was some form of certificate the site could present which would allow the user agent to validate the site's identity?

Regardless of that, it is unacceptable for a browser to be claiming that all page content came from an authenticated source, when that is patently untrue.

That isn't what the browser padlock is claiming. It's validating the cert for the original page. It's up to you if you trust that vendor to follow appropriate security practices in all aspects of that site. The 3rd party script issue you seem keen to highlight is only one of many vectors.

[bd139]

Also with 3rd party scripts, you can set the content security policy headers as per https://www.w3.org/TR/CSP/ which eliminates that possibility entirely.

Set up TLS properly, get an EV cert, pin your certs, set up CSP, set up HSTS.

You have to trust both peers either way. The remote peer you have to assume that the CA is valid and did their job. Looking at the fuck ups recently with verisign and symantec, it's all bollocks. The local peer you have to assume that your cert store is valid and that the software is trustworthy.

Typically you can MITM ANYTHING easily if you have access to the cert store on the local machine. If you have a trusted CA root and issue a cert on it then sign this, the browsers will trust it (Google are the only people walking away from this quickly and issuing revocations). At that point any intermediate node with that CA authority can issue a cert with the CN set to the host name and MITM your traffic. That's how corporate firewalls work and some insidious malware.

SSH is the only way to do this properly. It doesn't have a PKI that requires a third party authority. You can choose to trust them not delegate that trust to an anonymous band of crackpots lie symantec. Problem is it's inconvenient doing key distribution this way and most idiots just click yes to a host key prompt so you're screwed anyway.

Ugh it's all a mess and we're going to die one day so everyone just does what they can to tick the Qualys SSL Labs and pen testers boxes, then goes home and rocks in the corner crying.

[apelly]

Been doing a bit of research into this, and the results are just slightly worrying.

No they aren't.

HTTPS protects your communication from eavesdropping and manipulation while browsing the web. Well.

https://security.stackexchange.com/questions/5126/whats-the-difference-between-ssl-tls-and-https#5127

Troll much?

[IanMacdonald]

1: Almost all ads are served by javascript. You can't serve ads by javascript and not run javascript. 

If not you'd have to insert the ads directly into your page before it's sent. You could do that statically, but only for a fixed set of ads. In theory, PHP can grab the contents of a foreign page and then inject the HTML into the current page. In doing so it could grep for malicious code and remove it. That would be a lot safer, but it would require a lot more preparatory work by the webmaster. Which is why it's not so common. It would also require that the main site's host act as a gateway for the ad traffic, which would probably not go down too well.

2: CSP is so convoluted a topic that few people understand it. Which means, few webmasters will implement it. In any case, I don't think it can control the actions of a script once it is running in the context of the current page. If a page is to allow javascript ads, then it must relax the CSP to allow that. If the ads were run in a frame then it might be possible to sandbox that frame with CSP. Not sure about that. 

Normally, frames and popups opened from the same site can access the opener's properties, thus running ads in a frame or popup of some kind is not in itself a protection against them spying on the main page. Doing the login in a popup is a protection from ads on the main page, but only because js cannot enumerate windows.  Not so with a frame, because the frameset can be enumerated.

The main point though is that since the end user has no way of telling if a CSP is effect, that implies that the 'padlock' does not indicate a safe site. The objective here is to tell the user if the site is safe.

3: Quoting propaganda posted on stackexchange proves nothing. If repetition made things true, we'd all be running everything on magnet motors.

[bd139]

CSP is easy. Just RTFM

[Ash]

I have demonstrated that it is possible to MITM HTTPS. 

Ok, lets get this clear - a Man-in-the-middle attack is when a third part can impose themselves in between the server and the client and view all traffic with neither the client or the server knowing.

This is only possible in https if a new trusted root certificate authority public key is installed on the client computer. The MITM will then be able to issue a new certificate in the name of the web site signed by the (bogus) new key. The computer will then trust that the fake certificate is legitimate.

To do this requires either a corporate network where the machine joins the domain and is issued with these certificates so that the (trusted) corporate filewall can do this to inspect traffic, or a piece of malware has installed the certificate (this includes stupid OEMs installing dumb ass software tools).

I have done so, using two HTTPS sources. Also that it is trivially easy to do so. Jawdroppingly easy. I suspected such for a while, but hadn't gotten round to testing it out.  There may be ways of mitigating the attack, and it is possible that sites with advertising are employing them. The issue here is, how do you tell if any given site is using them? If a given site is NOT, then it is not safe to log in at that site. However, you have no way of determining that.
Which really puts us back to square one, that we don't know if any given site is safe.

Regardless of that, it is unacceptable for a browser to be claiming that all page content came from an authenticated source, when that is patently untrue.

Again, you have not demonstrated any MITM attack.

You have shown that a browser will, when instructed to by the code on your site under your control include a script from another source. This is the absolutely correct behaviour and how may things on the internet work.

The included script from the other site WAS authenticated using its own site's https certificate etc. If this failed it would not have been loaded.

An important point here, is that a browser will either refuse to load or warn the user if you ask it to include a script from a non-secure (http) source in a secure (https) page.

The 'Hash becomes the password' rebuttal is one which crops-up in numerous places. It seems to be in the nature of a 'canned response' the promoters of HTTPS have advised their supporters to use. It is BS. Hashes are normally salted They do not become the password.   

Um.. this rebuttal that you so glibly put down as a canned response is reality, sorry if it doesn't fit your view of the world.

Lets take it step by step.

• A (secure) hash takes the password and applies either a key or salt to the plain text resulting in the "Hash". Let us assume that this is done in the browser
• The browser now submits this hash along my by user name (or similar) to the server over a HTTP connection
• The server receives the hash and user name, and looks this up in its database
• The server can't do anything with the hash, it doesn't know the password, it has to use what it got
• It therefore can only store what was given (sure it could hash it again, but that doesn't add any security to the password), so it does a check against what it stored
• User is "signed in"
• Sadly for this user, they were using an open WiFi connection at a local restaurant... I'm sitting on the same WiFi network running some tools that allow be to dump WiFi traffic in promiscuous mode.. Hum.. interesting a signing request to insecurebank.com, I wonder...
• I take the plain text http request I saw on the wire and play it again. What happens?
• Server sees request, server looks at user name and hash, server validates hash. Bingo. I can be you.
• The hash is the password

The hash can not change. You can't change the salt/key because the server can't "recompute" the hash to verify it. You can't adjust the iteration count over time to maintain a suitable computation challenge (see PKDBF2) Basically proper hashing does a lot of work (designed to take noticable time on a modern computer, but this threshold should be adjustable. If the server is securely passed the password, it can check it against is current hash, then upgrade is internally stored hash to the new configuration to mitigate risks of passwords being broken should they be stolen.

If you are sending the hash to the server, what do you do? if you choose to just save the hash in your database, then you have failed. because now If I get your database, all the details I need to directly log in are in that file. If you hash the hash, you are in exactly the same position as you would be if you sent the server the password over a secure channel, so why all the extra work. And the secure channel tells the client and end user that they are talking to who they think they are talking too.

We *KNOW* that passwords get stolen from Web and database servers, and in vast numbers. That, is an incontrovertible fact.  Meanwhile, as a justification for the HTTPS rollout it is surmised that passwords are being stolen by ISPs, purely because that is technically possible. Being possible, however, does not mean it is taking place. 

For that matter, my ISP is theoretically able to debit any amount they want from my bank card. Being possible, does not of course mean that they do. However, applying the HTTPS argument would require that some way of preventing this activity MUST be implemented, purely on the basis of it being a theoretical risk. I don't see that happening. Why not?

Likewise there is nothing to stop my neighbour from picking up her kitchen knife, coming round here and killing me with it. The theoretical possibility exists, bur I do not regard the probability of that happening as being sufficient to demand any special security measures. If we start trying to cover every possible theoretical risk, the situation soon gets out of hand.

On the other hand I have a dashcam because I know there is a documented risk of fraudulent insurance claims, road rage incidents and so on. The risk I am covering is not theoretical.

The pragmatist in me says that all this time and money spent on HTTPS is time and money wasted that should be spent on fixing documented security issues. Rather than hypothetical ones.

Ok, ISP are not the problem. They are a business and are protecting their interests - what would happen if it got out that they were doing this? And if your bank lets you sign in without https, you need a new bank, yesterday.

You have to worry about the guy in the corner on your free wifi running Kali Linux sniffing all the wifi traffic for fun and profit.

Ash.

[madires]

In which case, if the purpose is to stop your ISP from snooping, then that protection is very easily circumvented. 

Which would underline that the only dependably secure HTTPS connection is a single origin one.

The problem of "fake" certificates of MITM proxies and rogue CAs can be solved by DANE.