
Is This Site Secure? - tigerlily
http://www.kermitproject.org/secure.html
======
omk
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.

~~~
phh
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.

~~~
bulatb
_> When we say "MITM" who is this man?_

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.

------
thenewnewguy
> 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.

~~~
tooop
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.

~~~
achtung82
But hes not arguing against EVs (that argument would be very valid).

------
girst
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.

------
lvh
This site also invites me to run a pile of code shipped from it:
[http://www.kermitproject.org/ckscripts.html](http://www.kermitproject.org/ckscripts.html)

\-- so yes, it matters that I'm actually talking to kermitproject, and they
should go get a LE cert.

------
skeeks
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...

~~~
moviuro
> 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.).

~~~
lvh
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.

~~~
moviuro
> 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]

[0] [https://www.troyhunt.com/extended-validation-certificates-
ar...](https://www.troyhunt.com/extended-validation-certificates-are-really-
really-dead/)

~~~
johncolanduoni
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).

------
kalleboo
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.

[0]
[http://www.kalleboo.com/retrotech/screenshots/powerbook-145b...](http://www.kalleboo.com/retrotech/screenshots/powerbook-145b/netscape-
mypage.png)

~~~
pixl97
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.

------
cia-killer
I wrote a script using mitmproxy to give the true answer.
[https://i.imgur.com/muFLWBT.png](https://i.imgur.com/muFLWBT.png)

------
deif
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.

------
IAmGraydon
> Probably browser makers like Google get "rewards" from the security
> companies for adding this feature.

This seems like quite a jump to me, and it underpins his entire argument. Is
there any evidence of this?

~~~
achtung82
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?

------
ChrisSD
It surprises me how often Betteridge's law of headlines is true

> 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...](https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines)

------
Kenji
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.

~~~
pixl97
If I mitm you, your plain txt website now serves 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.

~~~
bulatb
Or modify a TIFF or JPEG or whatever to attack the parser. That ancient system
with no modern crypto that can only do HTTP is fully patched, right?

------
kissgyorgy
There is a big reason left out of his argument: privacy of the user who is
reading the page. Essentially non-existing on HTTP.

------
bouke
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.

~~~
thenewnewguy
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.

~~~
bouke
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.

~~~
zahllos
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.

