The real dangers on the web come from the insane behavior of running all arbitrary code sent to the browser from anywhere. Like opening every email attachment you get sent. NoScript temp whitelist only provides a lot more safety than HTTPS Everywhere and doesn't give all power to a few corporations.
Now let's say you installed uMatrix and you want to trust a script. Well, how do you know that the script you downloaded came from the URL you've allowed? If you've requested this script before, then you can use a content hash, but if not, then you're basically blindly trusting that no one has tampered with the data.
But is uMatrix to trust?
Can you trust uMatrix developers?
I have bought a pair of shoes from an HTTPS only web sites, shoes never arrived, HTTPS apparently can't fix everything.
Trusting trust is a problem since computing was invented. [1]
[1] WARNING! PDF! https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...
Yes, it's hard to figure out whether or not to trust uMatrix. But I'd rather not make that even harder by allowing basically anyone to intercept and modify the code that uMatrix is sending at any time.
Even if SMS are "easy" to intercept, even if I send you an email with the SHA256, using a side channel greatly improve security, unless you're being targeted on multiple channels, which is quite uncommon.
For the same reason, even an MD5 hash is good enough most of the times. Even if it's been proven not secure years ago, it's secure enough to trust that in the general case the odds of generating the same hash while also creating something that is not simply broken, but it's malicious, are very, very low and require effort.
the point is: HTTPS still relies on trusting things we can't control and we will probably never control.
We are forced to trust HTTPS because there is nothing more we can do.
> But I'd rather not make that even harder by allowing basically anyone to intercept and modify the code that uMatrix is sending at any time.
But the reality is that it is hardly "everyone"
a MITM must be, by definition, in the middle.
Debian survived for decades delivering their packages over HTTP
Your blog isn't doing that, and none of your readers are verifying the hashes. If signature checks aren't being done automatically within the software, then for all practical purposes they might as well not exist for the vast majority of people.
Sending an SMS with a sha256 is bad security because for the average person it is equivalent to just sending them an SMS message. They will not verify the sha256 and it is impossible to train them to. And sure, I use SMS for some stuff, but I don't pretend that it's secure or that encrypted messaging doesn't matter because trusting trust isn't a solved problem yet.
> Debian survived for decades delivering their packages over HTTP
No, Debian used what is essentially their own certificate authority (PGP and Web of Trust). Your blog does not have the same security guarantees as Debian's package manager, and the fact that Debian relies on package signing using PGP and Web of Trust is strong evidence that they do believe that in-software automatic verification of message integrity is important for delivering code.
Everyone acts like Debian is proof that you don't need security, but package managers throw error messages when package signatures are wrong, just like your browser does when it can't verify an SSL cert. Because in both cases, verifying message integrity matters, even though it doesn't get rid of the entire problem of trust on its own.
> But the reality is that it is hardly "everyone" [...] a MITM must be, by definition, in the middle.
It's enough people. It doesn't have to literally be everyone on the entire planet. You should not be multiplying your attack vectors unnecessarily when there are trivially implemented, free, widely available methods for removing those attack vectors.
----
What a lot of this boils down to:
> For the same reason, even an MD5 hash is good enough most of the times.
There is a difference between leaving your shed unlocked because you're hoping your neighborhood is nice and no one will steal your lawnmower, and going onto a forum and arguing that locks are unnecessary because you leave your shed unlocked.
What you are essentially arguing here is not that HTTP is secure, you are arguing that bad security is OK. Which, fine, make that argument if you want, but "I don't need to be secure" is very different from "HTTPS doesn't matter for security."
I used HTTPS so our common friend at NSA knew what it was and sent a pigeon to your house.
How do you know that once you verified the hash, the software is safe?
btw, citation needed that the NSA is able to decrypt https traffic.
What if we're living in a black hole and our universe is a white hole?
> except we did a lot more work
Or we trust the sender to not be malevolent and/or compromised, like Debian did for more than 20 years.
I don't understand why people live like they are surrounded by enemies in enemy territory, given it's not usually the case.
HTTP is perfectly fine, unless you have reason to not use HTTP.
They exists, but it's not always necessary.
Also: 99% of corporate networks install self signed certs and override the certification authority, so traffic is inspectable.
Some mobile network operators do the same things when they sell to customers "secure network" upgrades.
HTTPS is not a panacea.
You simply trust a different set of "authorities" that none of us know or control.
I mentioned this above, but when was Debian ever doing this? I don't think I've ever used a package manager that wasn't at least making some attempt to secure against MITM attacks and compromised CDNs.
> Or we trust the sender to not be malevolent and/or compromised
That's not what HTTPS protects against, HTTPS is designed to protect against MITM attacks. It doesn't inherently have anything to do with verifying identity, and we've actively moved away from identity verification in the SSL world, because the companies trying to do identity verification to determine which certificates were "verified" added very little security to the process and were mostly a waste of money.
LetsEncrypt pretty much only cares whether or not you control the domain you say you control. It doesn't verify your identity past that point, because that's not its job. It solves a specific problem.
> Also: 99% of corporate networks install self signed certs and override the certification authority, so traffic is inspectable.
I don't personally like when companies do this, but it's not breaking HTTPS. If the user or device owner imports a certificate authority, then the browser should trust it. Isn't that the whole criticism people have with HTTPS, that they don't like gatekeepers? They should be happy that device owners can swap out certificate authorities.
> HTTPS is not a panacea.
Carrots and spinach are not a health panacea, but that doesn't mean I'm obligated to eat dirt instead.
There are definitely alternative schemes that could be used in the browser other than HTTPS. It's OK if you don't like HTTPS in specific. But that doesn't mean HTTP is secure.
They are still doing it!
On my system (this one's not Debian, but KDE Neon)
$ cat /etc/apt/sources.list
deb http://archive.ubuntu.com/ubuntu/ focal main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu/ focal-security main restricted universe multiverse
That need a MITM
Which is a specific type of attack.
If you are running a network where that's not possible, you're fine.
> LetsEncrypt pretty much only cares whether or not you control the domain you say you control
LetsEncrypt is pretty much an advanced tool, for advanced users
> I don't personally like when companies do this, but it's not breaking HTTPS.
It's breaking confidentiality.
Which is one of the features of HTTPS
In a corporate network MITM attacks are not that easy to pull off.
So basically HTTPS main feature is encryption of content in that context.
> Carrots and spinach are not a health panacea, but that doesn't mean I'm obligated to eat dirt instead.
first of all, carrots and spinach are a panacea.
Secondly, HTTP is not dirt.
Like SMTP is not dirt and IRC is not dirt and FTP is not dirt and TFTP is not dirt
> But that doesn't mean HTTP is secure. an ex nobody said HTTP is secure, but it's not inherently insecure, like every plain text protocol it's plain text.
it's the network that is insecure, MITM is not an exclusive of HTTP.
If the network is secure, HTTP is secure.
In my kubernetes clusters, TLS is terminated at load balancer and PODS talk to each other using plain simple HTTP.
Wasting energy on useless cryptography "just because" is not very smart IMO.
No, they're not! Debian uses PGP and signature verification to protect against MITM attacks because it is critically important for software downloads to be protected against MITM attacks.
Now, Debian does not use HTTPS in specific to protect against MITM attacks because they have another method baked into the package managers that people are using. It does not follow that HTTP is secure, it's not. It follows that you can use an insecure protocol to deliver software if you bolt the same security features on top of it.
You're looking at someone who has come up with an alternative way to protect users from MITM attacks and thus doesn't use HTTPS, and the conclusion you're drawing is, "I don't need to be concerned about MITM attacks." That's not the right lesson to draw from this.
Is your publicly facing site being accessed by software that automatically checks data integrity using a set of pre-shared keys? No, and no normal person is going to manually do that check when they visit your site, so you need HTTPS.
> If you are running a network where that's not possible,
If your website is accessible to normal browsers on the public Internet, than you're not on a network where that's not possible.
> LetsEncrypt is pretty much an advanced tool, for advanced users
Most free hosts I've looked at recently from Github pages to Netlify have automatic background SSL management for free with zero configuration from the user. If you're running your own server, then you're an advanced user, but even in that situation LetsEncrypt is one of the easiest SSL setups I've ever used.
Any situation where you're using a host who can't manage SSL for you is also probably a situation where you're using a host who can't manage things like DNS or hosting for you, at which point, yeah, I expect you to be able to run a command line tool. If you can install Wordpress on a server, you can use LetsEncrypt. If you can't install Wordpress on a server, you should be using a managed host, and they should install LetsEncrypt.
> It's breaking confidentiality. Which is one of the features of HTTPS
No, HTTPS encrypts data according to the certificate authority. While I don't like networks effectively doing MITM attacks on their own users, it is not the fault of HTTPS that it trusts the authorities that the user's device tells it to trust, any more than it's the fault of Debian if you import an untrustworthy key/repo into package manager.
I was kind of leaving privacy off the table here since you were championing Debian and Debian has substantial privacy issues with software downloads. But if you want to go down that route, than sure, another weakness of HTTP is that it allows tons of network snooping that really shouldn't be possible even for "innocuous" sites that claim they don't have private data on them.
> first of all, carrots and spinach are a panacea.
This is a complete sidenote, but either you don't understand what "panacea" means or you're at risk of Vitamin B12 deficiency. Carrots and spinach are not cure-alls for health, no.
> If the network is secure
It's not. Not if it's accessible from a browser on the public Internet.
> Wasting energy on useless cryptography "just because" is not very smart IMO.
Rejecting basically free cryptography that substantially improves security just because people are determined to be the last holdouts on a move that pretty much every security professional recommends is cutting off one's nose to spite one's face.
People being so concerned about centralization that they start sending messages in plain-text and start arguing with people online that sending messages in plain-text is somehow better for decentralization is at best misguided.
so YES, they are still doing it.
thanks for confirming.
Anyway, how do you donwnload those PGP keys in your opinion?
http://subkeys.pgp.net/keys/ http://pgp.mit.edu/ http://keyserver.ubuntu.org
Why they do it?
because the heavy cryptographic computation this way is done on the client, saving computer cycles on the packages mirrors that more often than not are kept alive by volunteers using their own money and time.
> If your website is accessible to normal browsers on the public Internet, than you're not on a network where that's not possible.
*If you are running a network where that's not possible,*
again, thanks for confirming it.
anyway, I could not care about MITM attacks if my website is my personal blog, running on a PI in my living room.
It's the network job to ensure security from MITM, not the website owners'.
> Most free hosts I've looked at recently from Github pages to Netlify have automatic background SSL management for free with zero configuration from the user
And now you have to trust them too, it's not "your personal website" anymore.
Talking about trusting trust... your solution is more delegation to unknown entities.
Doesn't sound so convincing to me.
> No, HTTPS encrypts data according to the certificate authority
No, HTTPS works with self signed certs too, it's browsers that don't want you to and show a scary popup like this
https://help.univention.com/uploads/default/original/2X/5/5e...
Which is not even true, the connection is private, it is simply privately private and not "trusted" by any know CA.
which could not be a problem if I trust the website and who runs it.
But, again, the scary warning page will scare people away, while the connection is working as intended.
> I was kind of leaving privacy off the table
You are confusing privacy with secrecy.
HTTPS is not private, the connections being made are still visible.
> you don't understand what "panacea" means
I'm Italian with Greek roots, we literally invented the word.
Its original meaning is "plants that cure everything".
That's why my remarks.
It's still a plant name! (https://www.google.com/search?q=p%C3%A0nace)
> Rejecting basically free cryptography that substantially improves security
Yeah, I imagine you lock yourself in your house and set the alarm every time you exit from a room and then disable it every time you enter, after unlocking the door.
I'm sure you do it, it's free, it improves security!
> People being so concerned about centralization that they start sending messages in plain-text and start arguing with people online that sending messages in plain-text is somehow better for decentralization is at best misguided.
I know how you feel in your paranoia fueled World and I feel for you, but I tell you, dear friend, that you're wrong.
Nobody said what you're saying they did.
Use the easier solution available given the circumstances is simply sign of intellect.
You're not stupid, I'm sure of it, so why you acting like you were?
You are completely missing the point. Debian does key verification. It does not naively trust that nobody has MITMed the connection. It's not just sending you code and keys and then shrugging and saying, "well, the network should have made sure they were good, so we're just going to run the package."
Debian is not an argument for disregarding MITM attacks. Debian cares about MITM attacks. Debian is also not an argument for ridiculous claims like "it's the network's job to protect me." Debian does not trust the network.
----
> Which is not even true, the connection is private, it is simply privately private and not "trusted" by any know CA. But, again, the scary warning page will scare people away, while the connection is working as intended.
The browser can not guarantee that connection is private. The reason why a browser shows a warning for a self-signed certificate is because there is no guarantee that the certificate itself is not a MITM attack.
This is entirely sensible and it would be grossly irresponsible for the browser not to show a warning. The way you get around that warning is you manually verify the certificate in a way the browser can see, and once you've done that, the warning goes away.
Note that Debian does the exact same thing, if you download a package that isn't linked to a key that your package manager knows to trust, it gives you a warning. Because of course it does, it would be ridiculous for it not to.
----
> Talking about trusting trust... your solution is more delegation to unknown entities.
What are you talking about? If you are using a managed host then you are already trusting that website to send files and host files. It's ridiculous to act like them also holding a certificate somehow makes you more dependent on them. Having a web host manage your SSL adds no additional dependencies or vulnerabilities to a managed site.
It's like using a managed host to serve HTML files and then getting upset that they also serve CSS files. It doesn't make any sense, you are trusting that website to send files. Not everything is a conspiracy to take away control. It's still "your website" to the extent that you trust "your website" to be hosted on somebody else's computer.
And yes, I am proposing delegation, because if you don't know how to do security then the responsible thing to do is to delegate to someone who does know how to do security.
On the other hand, if you are self-hosting off a Raspberry Pi in your living room, then no, I completely disagree that LetsEncrypt is too complicated for you to set up, or that it adds any substantial increase in complexity or difficulty to that self-hosted website, and I consider it to be pure FUD to try and claim otherwise. If you know how to set up DNS for a self-hosted website, then you are capable of setting up LetsEncrypt.
Now, if your website is only accessible within your NAT, then do whatever the heck you want, I couldn't care less. Send your data over unencrypted Bluetooth for all I care. But it's still not fantastic security and also why the heck are you coming onto public forums and arguing about what public websites do? If you're on a public network, you have to care about MITM attacks.
----
> Its original meaning is "plants that cure everything".
Spinach and carrots do not cure everything. They aren't even a nutritionally complete meal on their own, let alone cure every disease.
----
> Yeah, I imagine you lock yourself in your house and set the alarm every time you exit from a room and then disable it every time you enter, after unlocking the door.
Hey, at least I didn't remove the locks from my car doors because I was scared that the Toyota was going to use them to take control of my car.
The argument here is not that anything that increases security is good, the argument here is that when you have an effectively zero-cost security improvement for most people, and that security improvement protects people against real attacks that have been regularly exploited by both criminals and governments -- maybe it makes sense to turn those security measures on.
Metadata privacy as well as general browsing privacy is increasingly being shown to matter more and more online, not less and less. When we're in a situation where increasingly it's becoming easier and easier to use metadata in nefarious ways, it actually makes a lot of sense to just universally protect metadata and browsing privacy.
On that note:
> if my website is my personal blog
Imagine being so confident that your blog will never give important enough advice or say anything controversial or impactful enough to warrant encrypting it. Imagine being so confident that your blog will always be so mainstream that readers will never have a reason to hide that they're looking at it.
And then imagine thinking that a blog that innocuous and uncontroversial would ever need to care about how it's hosted or who's doing the hosting. If you're so convinced that nobody will ever care enough about what you write to warrant encryption, then stick your blog on Github pages and save yourself the extra electricty costs, because nobody is going to care about censoring something that isn't important enough to warrant encrypting.
----
> Use the easier solution available given the circumstances is simply sign of intellect.
There is no good reason not to have encryption on a publicly facing website: it costs nothing, it has substantial upsides, and the only reason not to do it is stubbornness.
The only arguments I've heard against encryption are centralization and complexity, neither of which are good arguments against encryption. Relying on a network for security makes your website less portable and increases your reliance on 3rd-party infrastructure far more than HTTPS does. Out-of-band verification is far more complicated and computationally expensive than in-band message verification, both in computing terms and for your users. Neither are good arguments.
It's just stubbornness, paranoia that LetsEncrypt secretly has some plan to control the world, outdated attitudes about the computational costs of TLS. I'm not going to pretend it's a respectable security position, the entire security industry has rejected arguments against HTTPS.
If you're that concerned about Internet centralization or about companies taking away control of "your website", then honestly, go complain about DNS in general; current DNS systems have way more impact on centralization than encryption does. Being anti-HTTPS is such an arbitrary, misguided hill to die on.
----
> It's the network job to ensure security from MITM, not the website owners'.
This is a bad security policy and should be discouraged.
If you can guarantee security within a network, great. But effective security is not about playing a blame game, if you are on a public network transmitting data then it is your job to care about MITM attacks. Security at the network level rather than at the message level has been consistently shown to be bad policy pretty much across the board. It's why we've started to move towards E2EE in many situations.
This is the most common challenge type today. Let’s Encrypt gives a token to your ACME client, and your ACME client puts a file on your web server at http://<YOUR_DOMAIN>/.well-known/acme-challenge/<TOKEN>. That file contains the token, plus a thumbprint of your account key. Once your ACME client tells Let’s Encrypt that the file is ready, Let’s Encrypt tries retrieving it (potentially multiple times from multiple vantage points). If our validation checks get the right responses from your web server, the validation is considered successful and you can go on to issue your certificate. If the validation checks fail, you’ll have to try again with a new certificate.
Our implementation of the HTTP-01 challenge follows redirects, up to 10 redirects deep. It only accepts redirects to “http:” or “https:”, and only to ports 80 or 443. It does not accept redirects to IP addresses. **When redirected to an HTTPS URL, it does not validate certificates** (since this challenge is intended to bootstrap valid certificates, it may encounter self-signed or expired certificates along the way).
[1] https://letsencrypt.org/docs/challenge-types/#http-01-challe...
1. LetsEncrypt has additional methods to help mitigate the risk of MITM attacks for HTTP-01 challenges (https://community.letsencrypt.org/t/validating-challenges-fr...)
2. LetsEncrypt has restrictions on HTTP-01 validation (no wildcards) that are designed to mitigate the fallout from exploits of this vulnerability.
3. There are proposals active to try and allow website operators to disable HTTP-01 validation entirely using DNS. It's not infeasible to me that HTTP-01 could end up being retired eventually, at least for websites that have public DNS records.
And most importantly:
4. This is treated as a vulnerability
LetsEncrypt is not saying, "MITM attacks don't matter and HTTP is good enough". They're working on a fundamentally difficult problem (how to do identity verification for the first time when all communication methods are subject to attack), and they are rolling out the best solutions they can come up with at this time; solutions that are tangibly better than the status quo of HTTP.
That is very, very different than saying, "oh, HTTP is fine for this, we can ignore working mitigations that would be easy to deploy." If there was an easy way to completely mitigate HTTP-01 attacks, LetsEncrypt would be doing it.
Who ever said they do?
Why are you side tracking the discussion?
> The browser can not guarantee that connection is private. The reason why a browser shows a warning for a self-signed certificate is because there is no guarantee that the certificate itself is not a MITM attack.
I can check the certificate, if I have a copy from a trusted source.
The point of the scary warning (that I cannot disable) is that nowadays tech thinks of people like children to be protected from themselves, instead of educate them to understand the risks.
> There is no good reason not to have encryption on a publicly facing website
There are, actually.
None of them are good reasons for you.
An example from another post of mine [1]
Imagine you built an app for weather reporting, the app downloads static json from a server using the hardcoded ip address
What is the added value of putting HTTPS in front of the stupid web server serving stupid static Json?
What would anyone gain by MITM it, admitting someone can or want to do it?
There are many other ways to break an app like that...
If you can put yourself in the middle, you can simply break the trust chain and you broke the app, even on HTTPS.
there's no need to replace the content.
Assuming there's value in doing it.
> neither of which are good arguments against encryption
Who ever said no to encryption or HTTPS BTW?
the original post talked about HTTPS everywhere, that's what are we talking about, is it so hard to stay on topic?
Anyway, I can send encrypted data over HTTP if I wanted to.
> It's just stubbornness, paranoia that LetsEncrypt secretly has some plan to control the world
None of that corresponds to nothing that's been said here, not by me anyway.
It's just that HTTPS doesn't protect anybody from a stubborn malevolent actor with enough resources and motivation.
It should be said, instead of pretending that HTTPS is completely fine.
HTTPS is fine like OpenSSL "audited by million of developers' eyes in the World thanks to open source" was fine.
> This is a bad security policy and should be discouraged.
The fact that it's their job, doesn't mean encouraging it as a policy.
It's just a fact.
If you don't agree, ok, but if you agree why twist my words?
> if you are on a public network transmitting data then it is your job to care about MITM attacks.
I'm not transmitting, I'm delivering. Which is different.
Deliver happens on demand.
Transmitting is more similar to what a broadcaster does.
And even though broadcast radio and TV frequencies have been open and public for decades, they rarely have been hijacked.
Main reasons are: lack of resources and because it's prohibited by laws that are actually enforced.
> It's why we've started to move towards E2EE in many situations.
Which is, in fact, better than HTTPS as it is today in my opinion.
Every example you're bringing up for ignoring HTTPS in the real world is by services that have alternative methods for protecting against MITM attacks -- methods that are built directly into clients that don't require external validation. You are trying to use that as justification for why you don't need to care about MITM attacks; but setups like Debian, LetsEncrypt, etc... are fundamentally different from the types of situations you're talking about where you want to ignore HTTPS. You are arguing that you should be able to ignore security measures, and that users shouldn't be warned that you are doing so.
----
Fortunately, I did some thinking about this, and I do feel I've been approaching this discussion in the wrong way. And I think I've managed to come up with a solution that can make both of us happy:
- You don't need to worry about MITM attacks, you can leave that all up to the network, it'll handle keeping the users secure. That's it's job, not yours. Basically, you can do whatever you want, and the network will protect its users.
- The way the network will protect its users in this particular instance will be by putting big scary warnings in front of sites that it can't guarantee are delivering their content securely.
So everybody wins. I think this is probably the best solution; you get to deliver your content however you want, and the network takes whatever measures it deems necessary to keep its users secure.
But I agree this conversation is going nowhere. TBH, I think the person you're replying to just isn't very smart. They can follow a single logical step, e.g. "I use this thing [Debian] and it doesn't use HTTPS." But they're incapable of making the N logical steps required to get from their example to the root of trust. In the example above, the root of trust is the download source of Debian.
How do you plan demonstrate that in my local network, connection between my computer and printer web based interface? Generally, we had several decates HTTP as main protocol and that worked out.
It could be one of your public IP addresses—more likely with IPv6, but still possible with IPv4—and not simply "squatting" on someone else's assigned public IP address. The browser may not be aware that these are local.
With that said, the devices should use public domain names and obtain proper certificates for them via the ACME DNS challenge, which avoids the issue altogether.
actually, it is.
HTTP is perfectly fine. [1]
> Anyone can ready / modify what is being sent
Anyone can break a window and enter my house.
But I haven't aired a private army to patroll the windows.
NSA can break HTTPS, TGF exists and China Trusted SSL Certificates are a thing.
False sense of security is often more dangerous than a real sense of insecurity.
Edit: [1] how many of you don't terminate SSL at load balancer?
that's a very bald assumption, my dear friend.
But in practice, yes, it is safe do not care of the possibility that someone is going to inject a script in your blog header, because I am no police officer, I do not work overtime, fighting crime. [1]
Same way I'm not worried that someone is going to steal my car and use it to rob a bank or worse.
> Do you use online banking?
Banks also have guards at the doors.
They handle other people's money, of course they care about it and about the safety of their employees.
Are you a bank?
> Do you care if you transmit your password to your bank account in plaintext?
Not really.
99% of my passwords are passw0rd on websites I really don't care about.
It is much harder, if not impossible, to guess my username.
I bet I am not the only one.
Besides, my bank ask me to confirm any operation in a MFA way.
If they notice something strange, they call me, on my phone, a human calls me.
It's their job.
> Would you really trust a phone number delivered over HTTP?
I've trusted for the majority of my life phone numbers sent unencrypted through wires that everybody could wiretap to and then by email...
Nothing bad ever happened.
Besides, what can happen if you call the wrong number?
I do not believe that the Grudge is a real story.
The point is: no, I am not paranoid.
Common sense is enough 99% of the times.
so has been HTTPS
> HTTPS on your site protects the rest of us from it being used by things like China’s Great Cannon.
I'm not scared by China, I'm scared by the fact that NSA already controls some of the certs in the so called "trusted" authorities, because, you know, "matter of national security" or "patriot act".
Oof, this just reminds me of the whole PRISM thing [0] where NSA was tapping inter-DC fiber links and Google wasn't encrypting (some of) the traffic between DCs
[0] https://slate.com/technology/2013/10/nsa-smiley-face-muscula...
But there's only a few Google around.
Besides, NSA can (and probably already is) collect encrypted streams and then try to break them offline.
Real time is not an hard requirement for them.
if what you are doing doesn't require secrecy, HTTP could suffice.
Imagine you built an app for weather reporting, the app downloads static json from a server using the hardcoded ip address.
HTTPS would add no benefit, worst that can happen is that someone hijacks the ip address (for some of the users, it's not possible to do it worldwide) and point the app to the wrong jsons, that might or might no be valid for the app.
Which is a lot of effort to break a weather app...