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

311–320 of 345 posts

Re: Still Why No HTTPS?

#311

Post by bullen »

necovek wrote: post #288
bullen wrote: post #275

Earlier quoted context omitted.

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

But "common pre-shared secret" (well, public key allowing verification that there is a trusted secret being used) is at the root of https security today (a preset list of root certificates distributed with OSes/browsers). If someone presents as your web site to a first time visitor (or a previous visitor but on a new device), there is no way for them to really trust your web site. Basically, it's the equivalent of yo…

Can you explain how root certificates makes anything secure? Why can't you just hack the root cert store on the local computer f.ex.?

There must be a million attack vectors to that system too, with a lot of attackers working on them since the payout is good when everyone uses the same system?

Even if it makes sense, since all governmental offices and some corporations have their own; doesn't that make you skeptic of that kind of centralized security?

I'd rather take my risks with something I can understand, modify and improve; than using what everyone else uses.

And again: It should be MY choice! Not googles, now I have to compile my own browser, which takes like 24 hours on a modern home PC!!!

Re: Still Why No HTTPS?

#312

Post by enriquto »

AndrewStephens wrote: post #185
enriquto wrote: post #128

Earlier quoted context omitted.

my static website is a sand castle in the beach. When I'm not around, kids may break it, or a random person may impersonate as its creator. That is alright, it is just a sand castle. The only purpose of its existence is to provide casual onlookers a nice view (or read) for a few minutes. Having to set up a "certificate" for that would be an unacceptable burden.

It is a sand castle on a private beach owned by you. Have you ever posted a link to your site anywhere? Imagine you sent me a post card saying "Come to my beach to look at my cool sandcastle" and then when I got there the sandcastle was actually a robot that stole my credit card. You could say that it wasn't your fault - somebody broke into your private beach and replaced the sandcastle. But I would probably still bl…

> Imagine you sent me a post card (...)

I like this. Post-cards are a better analogy for plain http than the sand castle.

Of course postcards are not "secure": everybody can read them, and you can trivially impersonate somebody else sending a postcard. Any serious snail mail communication must go via safer channels. Yet, postcards are a very nice thing to have, it would be a shame if they weren't possible. My kids can easily send a postcard to their grandparents, just by themselves. My grandfathers will probably (but nor surely) receive the postcard, and they will recognize who wrote them (but they can never be sure, really), and everybody will be happy.

In the same vein, HTTPS is better than plain HTTP for serious communication, and there's nothing wrong with it. Yet, the existence of HTTP is another fundamental part of the internet, and I make a point of using it as much as possible.

Do you propose that anonymous postcards shouldn't exist, and that the post office should only accept letters certified by adults who had identified themselves at the local police station? I would hate that! And for the same reasons I hate a world without http.

Re: Still Why No HTTPS?

#313

Post by printercenter »

To provide a real-time solution to for printer hitches, get in touch with the experts of printer service. All technicians are well-trained and have years of skills to resolve the glitches. https://printerhelpcenter.com/replace-brother-drum-error-mes... https://printerhelpcenter.com/how-to-fix-canon-printer-error...

Re: Still Why No HTTPS?

#314

Post by Thorrez »

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.

A non-verified cert can steal Secure cookies, no-cert cannot.

Re: Still Why No HTTPS?

#315

Post by Mikhail_Edoshin »

slim wrote: post #295
gmiller123456 wrote: post #279

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

7. it breaks caching proxies

I remember a discussion here on HN about how it makes life very hard for organizations like a school in Africa where the Internet connection is slow and expensive. Although many requests go many times to same pages (e.g. Wikipedia), HTTPS makes it impossible to cache them with a local cheap proxy.

HTTPS is cargo-cult'ish in this aspect. One obviously should not accept or serve personal data over HTTP, but why to encrypt public information? (Having said that I'm guilty here too as I blindly followed the instruction given to me by my hosting company and my plain open site redirects to HTTPS.)

Re: Still Why No HTTPS?

#316

Post by kuschku »

tialaramex wrote: post #201
BrandoElFollito wrote: post #126

Earlier quoted context omitted.

The problem is that I also have domains which are completely internal, not known/resolvable outside

This is probably a bad idea and I'd recommend migrating off such names as a background task. Realistically you can't entirely deconflict these names. So you always have a risk of shadowing names from the public Internet. The public CAs spent years in denial over this (yes they used to sell publicly trusted certs for "private" names, this is now prohibited). Create internal.example.com and things get easier. To the ex…

What's with domains such as blubb.mysystem.local or foo.invalid?

.invalid and .local are reserved domains and guaranteed to never be in use on the public internet - yet I can't get certificates for them

Re: Still Why No HTTPS?

#317

Post by kuschku »

necovek wrote: post #290

My biggest gripe with the current de facto recommended approach (even mandated in HSTS) is that you need to redirect to https from untrusted http. So you are being forced to either not serve http, or to condition users to trust MITM-able redirect. How many people will notice a typoed redirect to an https page with a good certificate? The solution is simple: browsers should default to https, and fall back to http if u…

That's what HSTS is for - you set a HSTS policy, and the browser will remember this site for a certain time you can set (usually 1-2 years).

And going further, you can enable HSTS preloading, meaning the next release of browsers is going to hardcode your website as always and only ever going to be used with HTTPS.

See for example my domain https://hstspreload.org/?domain=kuschku.de, which is currently in the preload lists of all major browsers including Chrome, Firefox, Edge and even Internet Explorer.

I also deploy the same for mail submission with forced STS, and several other protocols.

Re: Still Why No HTTPS?

#318

Post by zurn »

kuschku wrote: post #316
tialaramex wrote: post #201

Earlier quoted context omitted.

This is probably a bad idea and I'd recommend migrating off such names as a background task. Realistically you can't entirely deconflict these names. So you always have a risk of shadowing names from the public Internet. The public CAs spent years in denial over this (yes they used to sell publicly trusted certs for "private" names, this is now prohibited). Create internal.example.com and things get easier. To the ex…

What's with domains such as blubb.mysystem.local or foo.invalid? .invalid and .local are reserved domains and guaranteed to never be in use on the public internet - yet I can't get certificates for them

If you could get certificates for them, so could anyone else including your adversaries, since there is no system of ownership for them. It would be like issuing certs for https://192.168.1.1

Re: Still Why No HTTPS?

#319

Post by zurn »

BrandoElFollito wrote: post #124
zurn wrote: post #122

Earlier quoted context omitted.

It works over DNS. There is a lot written about it on the net, I don't have any specific recommended article.

I now how to do the check over DNS when the name is known outside - the problem is that I have my own internal domain not visible on Internet

You need a registered domain for this. It's a good idea for other reasons too.

Re: Still Why No HTTPS?

#320

Post by namibj »

Mikhail_Edoshin wrote: post #315
slim wrote: post #295

Earlier quoted context omitted.

7. it breaks caching proxies

I remember a discussion here on HN about how it makes life very hard for organizations like a school in Africa where the Internet connection is slow and expensive. Although many requests go many times to same pages (e.g. Wikipedia), HTTPS makes it impossible to cache them with a local cheap proxy. HTTPS is cargo-cult'ish in this aspect. One obviously should not accept or serve personal data over HTTP, but why to encr…

Soon we can properly sign HTTP requests using DNS for the PKI. Stuff like SRI inside HTML is paving the road to allow verification of hashes transmitted via header for the main page request, including a signature of that hash and url or such.

Sort of similar to how linux package managers employ GPG and package mirrors.

Or maybe we can provide caching based on signed-exchange.

Post reply on HN