Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Still Why No HTTPS?

troyhunt.com

Post reply on HN
Print view View original

271–280 of 345 posts

Re: Still Why No HTTPS?

#271

Post by gmiller123456 »

zozbot234 wrote: post #147
dm33tri wrote: post #144

Why do browsers punish non-verified certs much harder than no-cert? If I want to quickly host my page and use encryption, then I have go through all that hustle to make it work. Perhaps allow use of self-signed certificates on same level as http instead of blocking my website.

Do they? IME, they just ask you if you want to trust the self-signed certificate and allow you to optionally store that "trust" indefinitely, ending up with something like Trust On First Use. The warnings have to be scary initially because the security model is so radically different from the usual case of CA's; specifically, getting that "first use" validation correct is critically important.

The "trust this site" can be disabled, and usually is by many corporate policies. Additionally they use words like "unsafe" and "not trusted", but never use those words, nor big red screens, to warm against plain HTTP requests.

Re: Still Why No HTTPS?

#272

Post by daxelrod »

JackRabbitSlim wrote: post #264
couchand wrote: post #146

Earlier quoted context omitted.

One reason that comes to mind immediately: self-signed certificates offer no protection against MITM attacks. It's worse than without a cert, since it gives a false sense of security.

Which CAs have never been subject to a National Security letter? Can't say cuz you can't know? Lets talk about that false sense of security indeed.

This is one of the threats addressed by https://www.certificate-transparency.org/ .

If a CA issues a rogue cert and _does_ add it to the CT log, it's discoverable, at least in retrospect.

If a CA issues a rogue cert and _doesn't_ add it to the log, some browsers will refuse the connection when presented with that cert. https://www.agwa.name/blog/post/how_will_certificate_transpa... has more details about Chrome's implementation.

Re: Still Why No HTTPS?

#273

Post by lucideer »

ivanbakel wrote: post #269
mrob wrote: post #234

Earlier quoted context omitted.

So disable secure cookies by default for self-signed certs. The scary warnings can be shown when the user tries to enable them.

In other words, "open users up to social engineering attacks to make my web-dev life easier".

You misinterpreted the above commenter. The suggestion is to disallow self-signed contexts access cookies set in authoritative contexts.

Re: Still Why No HTTPS?

#274

Post by lucideer »

knome wrote: post #193
lucideer wrote: post #183

Earlier quoted context omitted.

I think the point here is that there's also no way to distinguish a http request from an attack. It's fair enough to an argue that a self-signed cert could be an attack, but so could any http request. > a no-cert (unencrypted) connection can be distinguished from an attack on an encrypted connection: the browser knows a priori (through the protocol in the URL) that the connection is supposed to be unencrypted. I don'…

Rightly punishing the connection for having the trappings of security when it actually lacks it doesn't mean we need to punish openly insecure traffic. End users have been told time and again that http is insecure, and so it's fine to leave it. End users should also be able to trust that https means secure without having to distinguish between secure and secure unless I'm being mitm'd and needing to understand what a…

To echo @mrob's comment (not sure why they've been downvoted), relying on user-understanding of HTTP -vs- HTTPS is considered a failed experiment, and actively discouraged. Chrome in particular are moving to bring this into the browser UI by marking HTTP sites as insecure (rather than relying on users understanding that HTTPS is secure, which they don't).

Re: Still Why No HTTPS?

#275

Post by bullen »

DuskStar wrote: post #257
bullen wrote: post #252

Downvote time: Why HTTPS? I made my own security: http://talk.binarytask.com

Do you have a description of how you made your own security and what it provides?

Last time I described it here on HN there was confusion.

It's just "single serving server salt" (try saying that fast 3 times) sent to "client for secret hashing" and then "sent back to server again", so it's insecure on registration (just like all security with MITM without common pre-shared secret) but after that it's pretty rock solid, even quantum safe. Requires two request/responses per auth. though.

This tech is nothing new and has been used by many big actors since forever. It's simpler that public/private encryption because it only requires hashing math to work.

It should be my choice to use whatever encryption I want without having google scare away my customers with "Not Secure".

Re: Still Why No HTTPS?

#276

Post by ridiculous_fish »

cesarb wrote: post #164
dm33tri wrote: post #144

Why do browsers punish non-verified certs much harder than no-cert? If I want to quickly host my page and use encryption, then I have go through all that hustle to make it work. Perhaps allow use of self-signed certificates on same level as http instead of blocking my website.

Since there's no way to distinguish a non-verified (self-signed or not) certificate from an attack, browsers have to treat them identically to an attack (otherwise an attacker would simply pretend to be a non-verified certificate, to get the more lenient treatment). On the other hand, a no-cert (unencrypted) connection can be distinguished from an attack on an encrypted connection: the browser knows a priori (through…

A known phishing message in gmail gets a red banner. An expired cert gets a full page block and buries the actual page link. It does seem disproportionate.

Re: Still Why No HTTPS?

#277

Post by ridiculous_fish »

maple3142 wrote: post #80
chungy wrote: post #9

Earlier quoted context omitted.

Instructions are here: https://certbot.eff.org/ I don't know how it could possibly be any simpler.

Maybe not everyone host website on a platform where you can easily install these things. For example, I have a simple web app hosted on Heroku free plan, and I have to use CloudFlare SSL to get it served over https on my custom domain. But it actually is half encrypted as the connection between CloudFlare and Heroku is plain http.

Right. Another example is that you cannot use https with subdomains on GitHub Pages.

https://github.community/t5/GitHub-Pages/Does-GitHub-Pages-S...

Re: Still Why No HTTPS?

#278

Post by necovek »

namibj wrote: post #173
zozbot234 wrote: post #159

Earlier quoted context omitted.

Well, a XHR cannot programmatically decide whether a self-signed cert should be trusted. Perhaps browsers should pop up a warning bar in such cases, explaining that some site functionality is being blocked for security reasons. Clicking it would take the user to the big scary warning page, where they would be allowed to indicate that they trust the self-signed cert (permanently or not) and reload the original page.

The XHR api could allow specifying a trust root and/or cert-pinning though.

How do you imagine this to work? XHR caller and XHR endpoint are both coming from untrusted sources at that point — if you allow either side to define a trust root, you are fully opening up to MITM attacks.

For development purposes, I imagine the approach akin to cross-origin support in browsers for loopback networks might work (i.e. don't enforce checks on them).

Re: Still Why No HTTPS?

#279

Post by gmiller123456 »

1. The requirement to involve a 3rd party certificate authority is a needless power grab. Giving in ends the hope that it will ever get changed.

2. There is currently only one free cert provider, if there are ever issues with it, your users will see a scary error message which will make them think there are security issued with your website.

3. Downloading and running code from a 4th, or 5th party and giving it access to your config files is not "more secure".

4. The culture of fear around HTTPS, meaning only the "most secure" or "newest" protocols and cipher suites are to be used. This prevents older clients from working, where HTTP works just fine.

5. HTTPS is needlessly complex making it hard to implement. There have been several security vulnerabilities introduced simply by its use.

6. If you can't comply with the OpenSSL license, implementing it yourself is a hopeless endevour.

SSL was developed by corporations, for corporations. If you want some security feature to be applicable to the wider Internet, it needs to be community driven and community focused. Logging in to my server over SSH has far more security implications than accessing the website running on it over HTTPS. Yet, somehow, we managed to get SSH out there and accepted by the community without the need for Certificate Authorities.

Re: Still Why No HTTPS?

#280

Post by necovek »

founderling wrote: post #70

Because there is only one free certificate provider (lets encrypt) and it does not allow wildcard certificates via server authentification. Having the DNS credentials laying around on the server is not a good idea. So creating wildcard certs via letsencrypt is a huge pain in the ass. If a webmaster has control over somedomain.com I think that is enough to assume he has control over *.somedomain.com. So I think letsen…

StartCom/StartSSL used to issue free certificates even before LetsEncrypt appeared, and it was a much bigger hassle to get verified, but at least they were valid for a full year. Not sure if they still do, and they didn't allow for multiple servernames in one cert.
Post reply on HN