Is This Site Secure?
kermitproject.org
kermitproject.org
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.
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.
Those same anti-TLS arguments have been rehashed often enough by now.
-- so yes, it matters that I'm actually talking to kermitproject, and they should go get a LE cert.
Really, 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...
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?
> 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...
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.
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.