Seriously? And what about Man-in-the-middle attacks?
I mean come on, there are files to download from that website? How can I know if the site I see is REALLY your site without https?
Really, I don't know why you just don't obtain a Let's Encrypt certificate, it's not difficult anymore...
> How can I know if the site I see is REALLY your site without https?
HTTPS has never been about non-repudiation or authenticity; it's always been about confidentiality. You get some half-assed "authenticity" if you didn't mistyped the domain, and your clock is correctly set, and the certificate authority wasn't compromised, and the web server wasn't compromised, etc.
You should use GPG or signify if you need authenticity.
HTTPS just prevents injection and monitoring, a bit (see SNI, sniffing downloaded sizes, etc.).
Confidentiality without authentication is not a thing. If I don't know that I'm talking to you, then I might be talking to a MITM attacker who's reading everything we're saying (and may or may not be altering it). It really is that simple.
Sure it is. Imagine a website with a self signed cert. You're over HTTPS and still encrypted, but it's you vs the (statistically unlikely) MITM entity holding that cert's private key, rather than you vs everyone in traceroute running wireshark. It's strictly better.
Granted this meant more before the days of LE, but you get what I'm saying.
Non-repudiation and authenticity are terms of art. By redefining them well outside of what everyone else means by those terms, I don't think you're helping discourse along. HTTPS _absolutely_ guarantees non-repudiation and authenticity. Casually dismissing the most important protocol on the Internet as giving you some "half-assed authenticity" is pretty silly, especially when one of your suggested alternatives is GPG, which literally can not get a damn MAC right in any mode actually deployed anywhere and instead has some weird superstitious MDC nonsense.
> HTTPS _absolutely_ guarantees non-repudiation and authenticity
No it doesn't. Correct HTTPS (i.e. connecting to a site with no errors) guarantees:
* the entity that requested the certificate at the date it did had control over either the website or the DNS for a domain (if it is domain-squatting, it's even legal)
* the Certificate Authority that did deliver that certificate did not suffer a breach; and otherwise followed protocol (CAA - which might be under attack, etc.)
* the client connecting did either: not check for revocation (often), not encounter errors while checking, or silently ignored the absence of reply when asking for the CRL/OCSP responder
And it's precisely because HTTPS doesn't guarantee any kind of authenticity that browsers themselves are dropping visual clues for EV certificates. [0]
And if someone palms your GPG private key, or the public key is not properly authenticated in the first place, you don't get any of the kind of absolute authenticity you're talking about either. You complain about CRL/OCSP, but a GPG keyserver has all the same flaws (with worse default configuration of clients).
.... you propose that HTTPS is insecure because someone could compromise the website, server, or CA? That precludes... pretty much everything from being "secure". If an attacker can compromise a website and CA, we should assume that they can compromise every other website and every software update server, thereby compromising >90% of computers on Earth inside a week, starting with anything connecting to the Microsoft and Ubuntu update servers.
Another reminder that we should fight for encryption by default, without requiring a validated certificate. Just self-signed like most end-ro-end encryption schemes. For such sites, browsers could not display a padlock to differentiate them from validated certificates (DV/EV).
Thus without any additional configuration, the data sent over those connections would be safe.
No they wouldn't, because this is trivially easy to MITM. The whole reason CAs exist is to verify the identity of the domain owner, because any random MITMer can claim to be yourbank.com and you can't prove it either way.
Very technically this would be slightly better because it stops passive observers, but in reality I suspect it would be worse because tons of websites would use this broken by design solution and think they were perfectly secure because encryption.
What we really need is to stop making HTTPS so hard to setup. It has gotten better in the last 5-10 years, but you still have to do this whole rigamarole with Apache2/nginx to disable weak cipher suites, setup all the right TLS parameters, etc because the default configuration is so bad. Imagine a world where I just installed an HTTP server and it asks me if I wanted to get a cert from Let's Encrypt (or any other ACME provider) and just did all the setup correctly for me.
There are two aspects that are currently adressed by https: identity and privacy. What I’m proposing does indeed only solve the privacy aspect. And for some use-cases, that’s fine. Not all use-cases (e.g. your bank), and we would still have CAs for that.
Having private communication without knowing who you're talking to is not private at all. You need to first define who you want to hide the communication from (assumedly, everyone except the server in question), and then also know that you're really talking to that server and not just someone claiming to be that server.
For example, if there were a class of websites where certificates were not checked, I could configure my router to man-in-the-middle attack every connection to one of those coming from anywhere in my own network, and then re-transmit information in the clear somewhere else. To someone inside my network, their browser would report their connection as being "secure".
Privacy is really the wrong word in my opinion. What you mean is confidentiality. This might sound like nitpicking, but private communication might mean that some attacker does not know who is talking to whom, which is not what TLS even tries to provide (anonymous communication). The term is somewhat overloaded. You can have fully encrypted communications and still give away information you intended to be private.
TLS does try to provide confidentiality and part of that is authenticating who you are talking to. Without this your communication is not at all confidential, as anyone could impersonate your intended target. A passive adversary can't read your traffic, true, but an active attacker (of for example the coffee shop dwelling variety) is not a major step up and would undermine the confidentiality aspect entirely.
I want privacy with the site I'm trying to connect to including when I do so for the first time. I don't care about privacy with whomever is running a MITM attack on me since that's rather pointless.
>Imagine a world where I just installed an HTTP server and it asks me if I wanted to get a cert from Let's Encrypt (or any other ACME provider) and just did all the setup correctly for me.
That is exactly what Caddy https://caddyserver.com/ does - except it doesn't even ask. Automatically setting up HTTPS is the default, zero-extra-configuration behaviour.
You walk into a random corner store for Tylenol and see the bottom of a cut-off box of cereal with pills inside. A cardboard sign in front of it says "Tylenol" and there's a logo clearly printed off a website gluesticked to the box. The pills are plausibly the right shape and color.
You buy a few and take your Tylenol without a second thought—right?
Maybe not. If that seems ill-advised, please don't propose the same for websites.
While at the begining I thought I sensed a bigger argument here, the further I read I am certain the author either prefers to discount MITM or lacks the understanding of the full scope of a MITM. I agree that there are other evils of the web but that does not mean we make trade-offs.
The last paragraph goes as far as to say
"The ad is not from the website; rather, it is inserted into the datastream — after it has left the Web server as it streams the web page to your computer — by your own Internet Service Provider (Optimum in my case). This is called "watermarking", a variation on the classic Man-in-the-Middle attack. So far it's an infrequent occurrence and not a major problem, and in any case definitely not a security risk, just Yet Another Annoyance"
You let go of your user's privacy and security the moment you make such a trade-off calling it just another annoyance. While visiting this site a MITM could possibly inject a malicius javascript or sticky cookie. How is that just an annoyance? Protecting this is the biggest selling point of HTTPS.
I don't agree with the article (mainly because I consider that switching to https is free enough for anyone doing web hosting), but still, the point is pretty clear. https feels like red herring.
When we say "MITM" who is this man?
In most cases, the only two valid responses really are "my ISP", and "the service's hosting provider".
https doesn't securize against evil hosting provider.
When using Chrome+https, vs Firefox+http, in one case you give your data to your ISP, in the other case to Google.
Google's primary focus is using my personal data. My ISP's primary focus is giving me Internet.
Google is making fuss about https, to feed noise about Google itself.
Yes, I totally agree that best is to simply Firefox https.
Yes, I'm totally dismissing the issue of rogue networks. But >80% of the population uses Google, I believe that less than 20% of the population is using rogue networks.
What about the issue of broken WiFi security? Well, the point stands: https is so much of a red herring, that everyone forgets to fix WiFi.
Anyone in `traceroute`, even indirectly. Your state. A rival state. Your ISP. Your neighbor at the coffee shop. A rogue employee at a CDN. A poisoned cache. That little thing that no one noticed in the closet. The latest malware on your router. Any of those threats on any path between the visitor and any resource on the page.
> I believe that less than 20% of the population is using rogue networks.
The network is hostile. Believing that it's not contributes to its insecurity: you get an architecture with a hard shell and a gooey center. One box in your "safe zone" gets popped and you're done.
So make the safe zone your box and nothing else. HTTPS helps you get there.
> What about the issue of broken WiFi security?
What about it? Someone snooping on your WiFi can't see through your TLS. That's a reason to support HTTPS, not to dismiss it.
No, their primary focus is to make money and they are finding that selling your data and showing you ads is profitable. Google hoards data so it can use it and I generally trust Google to keep the data secure. I don't trust my ISP to keep my data secure or not to sell it to everyone on the planet.
Security is about being paranoid in imagining what different actors can do with varying levels of access. In this case, MITM is not always easy, but once they have access they can do bad stuff. As a webmaster, an attacker with this access can break your site by messing with your users.
By taking the simple step of using https, you can successfully reduce your attack surface and increase the difficulty of messing with your site.
If unencrypted data in transit and an open man-in-the-middle attack vector are "definitely not a security risk", I cannot trust the author's concept of security, risk, or privacy.
I agree the author lost their argument partway through, and I would have made the point a bit differently.
Broadcast TV and radio signals are not secure, and don't need to be. Their information is supposed to be available for everyone. If someone hijacks a radio station, the worst they can do is spread disinformation, and there are easier ways to accomplish that.
Similarly, if all a website does is display text that is designed to be visible to everyone, a secure protocol is unnecessary.
IMO, http pages which lacks input fields and other forms of two-way communication should not receive an insecure warning. By contrast, if there's an input field, there's a good chance the user expects what they're writing to be private.
From a seemingly reputable source that people trust. Now take a 4chan prank like the home grown crystals and put it on a site like the NHS'. Grab one of the blogs of these people who post about https not being necessary and if they have any tutorial where they have terminal snippets to copy and paste you can own their reader's machines.
There are so, so many ways to do mischief if not outright ruin the lives of people in these websites that "just display text".
>Similarly, if all a website does is display text that is designed to be visible to everyone, a secure protocol is unnecessary
And how is the browser supposed to figure that out? If I can edit your data stream I can load up inline javascript that could add data submission in very hard to figure out ways.
Secure protocols dont just encrypt, they authenticate the originality of the data (at least from the https instance it was sent from).
Sounds like the author doesn't know about Let's Encrypt. Pretty simple and free way to secure your site with no disadvantage and it kills OPs primary argument.
This site serves executables and script files via HTTP. Those potentially dangerous files are thus neither encrypted nor - and that's the bad part - authenticated, meaning that any man in the middle can inject content that infects your machine.
I draw the line at this point. Serve with HTTP if you just have some text. Serve with HTTPS if you have logins, sensitive information or executables and scripts.
Yes, the phrasing "secure/insecure" is an abbreviation that loses a lot of meaning, but to dismiss TLS based on that seems dishonest. Even if you don't care about your user's privacy, don't you at least want the authenticity and integrity TLS provides? The author doesn't only acknowledge MitM, but even show an example where they themselves are MitM'd.
Those same anti-TLS arguments have been rehashed often enough by now.
> So Internet security has become a big and ongoing business, which has to be paid for. If I want to have a secure E-commerce site so I can make money, I have buy security services on top of the basic web services: an HTTPS address instead of the original HTTP: — OK, fair enough.
Has this guy not heard of Let's Encrypt? HTTPS certificates are literally free. I was astounded when I got to the end of the article and saw it was published in 2020 and not 2015.
He is probably assuming that e-commerce sites must/should use EV certificates. It could be an additional trust source but how many users really care that the cert is EVed.
It's even more interesting that they seem to be working with a file-transfer protocol. It seems to me like they should be experts in this field, and clearly not aware of Let's Encrypt.
My own website is on HTTP because I mainly edit it and browse it on old computers where modern encryption is not available[0]. I assumed it would be the same reasoning here, as who else is using Kermit in 2020?
Is anyone here using Kermit? Would love to know what for. Website seems to suggest it's for embedded systems, but I've only seen TFTP used in those cases.
Well, if someone was bored enough they could mitm your downloads and have fun with whatever computer they were loaded on. That said your not much of a target, but are still and easy one if someone chose to do so.
Isnt it the opposite that googles policy of showing same icon for DV and EV certificates are making it a lot more difficult for security companies to make money selling expensive EV certs?
50 comments
[ 3.5 ms ] story [ 79.1 ms ] threadReally, I don't know why you just don't obtain a Let's Encrypt certificate, it's not difficult anymore...
HTTPS has never been about non-repudiation or authenticity; it's always been about confidentiality. You get some half-assed "authenticity" if you didn't mistyped the domain, and your clock is correctly set, and the certificate authority wasn't compromised, and the web server wasn't compromised, etc.
You should use GPG or signify if you need authenticity.
HTTPS just prevents injection and monitoring, a bit (see SNI, sniffing downloaded sizes, etc.).
Granted this meant more before the days of LE, but you get what I'm saying.
No it doesn't. Correct HTTPS (i.e. connecting to a site with no errors) guarantees:
* the entity that requested the certificate at the date it did had control over either the website or the DNS for a domain (if it is domain-squatting, it's even legal)
* the Certificate Authority that did deliver that certificate did not suffer a breach; and otherwise followed protocol (CAA - which might be under attack, etc.)
* the client connecting did either: not check for revocation (often), not encounter errors while checking, or silently ignored the absence of reply when asking for the CRL/OCSP responder
And it's precisely because HTTPS doesn't guarantee any kind of authenticity that browsers themselves are dropping visual clues for EV certificates. [0]
[0] https://www.troyhunt.com/extended-validation-certificates-ar...
Thus without any additional configuration, the data sent over those connections would be safe.
Very technically this would be slightly better because it stops passive observers, but in reality I suspect it would be worse because tons of websites would use this broken by design solution and think they were perfectly secure because encryption.
What we really need is to stop making HTTPS so hard to setup. It has gotten better in the last 5-10 years, but you still have to do this whole rigamarole with Apache2/nginx to disable weak cipher suites, setup all the right TLS parameters, etc because the default configuration is so bad. Imagine a world where I just installed an HTTP server and it asks me if I wanted to get a cert from Let's Encrypt (or any other ACME provider) and just did all the setup correctly for me.
For example, if there were a class of websites where certificates were not checked, I could configure my router to man-in-the-middle attack every connection to one of those coming from anywhere in my own network, and then re-transmit information in the clear somewhere else. To someone inside my network, their browser would report their connection as being "secure".
TLS does try to provide confidentiality and part of that is authenticating who you are talking to. Without this your communication is not at all confidential, as anyone could impersonate your intended target. A passive adversary can't read your traffic, true, but an active attacker (of for example the coffee shop dwelling variety) is not a major step up and would undermine the confidentiality aspect entirely.
That is exactly what Caddy https://caddyserver.com/ does - except it doesn't even ask. Automatically setting up HTTPS is the default, zero-extra-configuration behaviour.
You buy a few and take your Tylenol without a second thought—right?
Maybe not. If that seems ill-advised, please don't propose the same for websites.
Tofu, like with ssh, is a valid strategy. Trusting third party providers is decreasing safety compared to only having you and the service.
The last paragraph goes as far as to say
"The ad is not from the website; rather, it is inserted into the datastream — after it has left the Web server as it streams the web page to your computer — by your own Internet Service Provider (Optimum in my case). This is called "watermarking", a variation on the classic Man-in-the-Middle attack. So far it's an infrequent occurrence and not a major problem, and in any case definitely not a security risk, just Yet Another Annoyance"
You let go of your user's privacy and security the moment you make such a trade-off calling it just another annoyance. While visiting this site a MITM could possibly inject a malicius javascript or sticky cookie. How is that just an annoyance? Protecting this is the biggest selling point of HTTPS.
When we say "MITM" who is this man? In most cases, the only two valid responses really are "my ISP", and "the service's hosting provider".
https doesn't securize against evil hosting provider.
When using Chrome+https, vs Firefox+http, in one case you give your data to your ISP, in the other case to Google.
Google's primary focus is using my personal data. My ISP's primary focus is giving me Internet. Google is making fuss about https, to feed noise about Google itself.
Yes, I totally agree that best is to simply Firefox https. Yes, I'm totally dismissing the issue of rogue networks. But >80% of the population uses Google, I believe that less than 20% of the population is using rogue networks. What about the issue of broken WiFi security? Well, the point stands: https is so much of a red herring, that everyone forgets to fix WiFi.
Anyone in `traceroute`, even indirectly. Your state. A rival state. Your ISP. Your neighbor at the coffee shop. A rogue employee at a CDN. A poisoned cache. That little thing that no one noticed in the closet. The latest malware on your router. Any of those threats on any path between the visitor and any resource on the page.
> I believe that less than 20% of the population is using rogue networks.
The network is hostile. Believing that it's not contributes to its insecurity: you get an architecture with a hard shell and a gooey center. One box in your "safe zone" gets popped and you're done.
So make the safe zone your box and nothing else. HTTPS helps you get there.
> What about the issue of broken WiFi security?
What about it? Someone snooping on your WiFi can't see through your TLS. That's a reason to support HTTPS, not to dismiss it.
No, their primary focus is to make money and they are finding that selling your data and showing you ads is profitable. Google hoards data so it can use it and I generally trust Google to keep the data secure. I don't trust my ISP to keep my data secure or not to sell it to everyone on the planet.
By taking the simple step of using https, you can successfully reduce your attack surface and increase the difficulty of messing with your site.
Broadcast TV and radio signals are not secure, and don't need to be. Their information is supposed to be available for everyone. If someone hijacks a radio station, the worst they can do is spread disinformation, and there are easier ways to accomplish that.
Similarly, if all a website does is display text that is designed to be visible to everyone, a secure protocol is unnecessary.
IMO, http pages which lacks input fields and other forms of two-way communication should not receive an insecure warning. By contrast, if there's an input field, there's a good chance the user expects what they're writing to be private.
From a seemingly reputable source that people trust. Now take a 4chan prank like the home grown crystals and put it on a site like the NHS'. Grab one of the blogs of these people who post about https not being necessary and if they have any tutorial where they have terminal snippets to copy and paste you can own their reader's machines.
There are so, so many ways to do mischief if not outright ruin the lives of people in these websites that "just display text".
And how is the browser supposed to figure that out? If I can edit your data stream I can load up inline javascript that could add data submission in very hard to figure out ways.
Secure protocols dont just encrypt, they authenticate the originality of the data (at least from the https instance it was sent from).
If it’s just a document/markup format, the warning strikes me as unnecessary. Mind, I realize that wouldn’t apply to many sites today.
I draw the line at this point. Serve with HTTP if you just have some text. Serve with HTTPS if you have logins, sensitive information or executables and scripts.
That's what everybody seems to miss. I can change your content type headers online.
In theory the only way this would work is if browsers would not do javascript at all, or any other type of executable content on http sites.
Those same anti-TLS arguments have been rehashed often enough by now.
Has this guy not heard of Let's Encrypt? HTTPS certificates are literally free. I was astounded when I got to the end of the article and saw it was published in 2020 and not 2015.
Im confused.
> Any headline that ends in a question mark can be answered by the word no.
https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...
-- so yes, it matters that I'm actually talking to kermitproject, and they should go get a LE cert.
Is anyone here using Kermit? Would love to know what for. Website seems to suggest it's for embedded systems, but I've only seen TFTP used in those cases.
[0] http://www.kalleboo.com/retrotech/screenshots/powerbook-145b...
This seems like quite a jump to me, and it underpins his entire argument. Is there any evidence of this?