Is This Site Secure? • Hacker News Board

Re: Is This Site Secure?

#31

Post by zahllos » Sat, Jan 25, 2020, 2:44 PM UTC

bouke wrote: post #16

thenewnewguy wrote: post #9

Earlier quoted context omitted.

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 th…

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.

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.

Re: Is This Site Secure?

#32

Post by lvh » Sat, Jan 25, 2020, 2:49 PM UTC

moviuro wrote: post #29

lvh wrote: post #19

Earlier quoted context omitted.

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…

> 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 fo…

As I stated in my original comment: sure, if you arbitrarily redefine what terms mean, HTTPS doesn’t provide authenticity or non-repudiation.

Re: Is This Site Secure?

#33

Post by bulatb » Sat, Jan 25, 2020, 2:50 PM UTC

phh wrote: post #23

omk wrote: post #4

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 lef…

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 Fir…

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

Re: Is This Site Secure?

#34

Post by johncolanduoni » Sat, Jan 25, 2020, 2:52 PM UTC

moviuro wrote: post #29

lvh wrote: post #19

Earlier quoted context omitted.

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…

> 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 fo…

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

Re: Is This Site Secure?

#35

Post by johncolanduoni » Sat, Jan 25, 2020, 3:01 PM UTC

phh wrote: post #23

omk wrote: post #4

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 lef…

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 Fir…

I'm a bit confused as to what this has to do with Google? What advantage to they get by promoting HTTPS if all the other browsers support it as well?

Re: Is This Site Secure?

#36

Post by marcinzm » Sat, Jan 25, 2020, 3:14 PM UTC

phh wrote: post #23

omk wrote: post #4

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 lef…

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 Fir…

>My ISP's primary focus is giving me Internet

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.

Re: Is This Site Secure?

#37

Post by marcinzm » Sat, Jan 25, 2020, 3:18 PM UTC

bouke wrote: post #16

thenewnewguy wrote: post #9

Earlier quoted context omitted.

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 th…

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.

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.

Re: Is This Site Secure?

#38

Post by Wowfunhappy » Sat, Jan 25, 2020, 3:28 PM UTC

omk wrote: post #4

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 lef…

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.

Re: Is This Site Secure?

#39

Post by captncraig » Sat, Jan 25, 2020, 3:29 PM UTC

phh wrote: post #23

omk wrote: post #4

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 lef…

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 Fir…

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.

Re: Is This Site Secure?

#40

Post by emilfihlman » Sat, Jan 25, 2020, 3:30 PM UTC

bouke wrote: post #3

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.

You are 100% correct and it's sad others cant see it.

Tofu, like with ssh, is a valid strategy. Trusting third party providers is decreasing safety compared to only having you and the service.