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

201–210 of 345 posts

Re: Still Why No HTTPS?

#201

Post by tialaramex »

BrandoElFollito wrote: post #126
benoliver999 wrote: post #121

Earlier quoted context omitted.

It's not easy but iirc you can do it with a DNS-01 challenge, if your internal domain name is valid (doesn't have to resolve to anything though).

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 extent security by obscurity is worth trying it's just as available this way (split horizon DNS etcetera)

Re: Still Why No HTTPS?

#202

Post by Ajedi32 »

kuschku wrote: post #110
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…

> 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. That's absolutely unnecessary Set a NS record for _acme-challenge.domain.tld to your own nameservers, e.g. ns1.myowndomain.tld And have your own name servers only serve the _acme-challenge.domain.tld zone. Now you can just use the RFC DNS updater with your ACME client with…

There's also ACME-DNS, which is a DNS server designed specifically for that use case: https://github.com/joohoi/acme-dns

Re: Still Why No HTTPS?

#203

Post by oarsinsync »

Ayesh wrote: post #54
namibj wrote: post #27

There is one "good" reason against https: handshakes take enormous amounts of CPU, relatively speaking. It's quite easy tp DoS server by skipping the expensive part on your end. You can load a core with 10~30Mbit@2k rps if your not even optimized. Whereas the same server could tank 40k rps HTTP requests.

This is an argument I hear often, but I have yet to see an effective L7 DoS with the TLS handshake being the bottleneck. It's almost always the application code that gives up, rather than the CPU spikes due to TLS. I have a 1 vCPU 2GB server that terminates TLS with dual Prime256v1/curve25519 + RSA 2048 setup with a 10 minute keepalive time, running AES 128, 256 (CPU has AES-NI), and CHACHA20-POLY1305 comfortably han…

> comfortably handling several millions of requests a day and CPU load hovering 10-20%

Parent suggested that at 172 million requests per day (2000 rps), there would be trouble.

Assuming "several million" is <= 17 million (or even up to 34 million, given the 10-20% range stated), then your stats would tend to agree.

Re: Still Why No HTTPS?

#204

Post by edoceo »

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.

It already does, put your self-CA in the browser trust store.

Re: Still Why No HTTPS?

#205

Post by forgottenpass »

As long as the worlds greatest surveillance system continues to be given deliberate access to the plaintext, I will continue not caring about HTTPS for websites that don't have users logging into an account or submitting forms.

Re: Still Why No HTTPS?

#206

Post by chuckhoupt »

lorenzhs wrote: post #57
signed0 wrote: post #19

Earlier quoted context omitted.

Weirdly nature.com seems to actually redirect to https, as does zara.com, lenovo.com, genuis.com, and senate.gov. Is this list stale, or did no one spot-check this?

Same with w3.org, which is fifth on the list, and ebay-kleinanzeigen.de. Seems like quite a few entries are off.

w3.org redirect to www.w3.org, but not HTTPS. This makes sense for the standards org that defines HTTP, and needs to maintain backwards compatibility.

Re: Still Why No HTTPS?

#207

Post by zamadatix »

UI_at_80x24 wrote: post #167
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.

>go through all that hustle.... I manage 100+ servers, hosting a significantly larger number of domains, on a variety of linux and FreeBSD operating systems. Under both Apache & Nginx. "..all of that hustle.." to initially setup is under 2 minutes with LetsEncrypt. The renewal (via a cron job) is completely out-of-sight/out-of-mind. The execution is shockingly simple. If you think it's "all that hassle" I guarantee y…

You're a professional plumber working on hundreds of households saying it's shockingly simple and should take no time at all for a first time home owner to fix their own plumbing. You've already got the knowledge, experience, and tools/parts in the van - of course you don't think it's a hassle!

Re: Still Why No HTTPS?

#208

Post by giancarlostoro »

zamadatix wrote: post #207
UI_at_80x24 wrote: post #167

Earlier quoted context omitted.

>go through all that hustle.... I manage 100+ servers, hosting a significantly larger number of domains, on a variety of linux and FreeBSD operating systems. Under both Apache & Nginx. "..all of that hustle.." to initially setup is under 2 minutes with LetsEncrypt. The renewal (via a cron job) is completely out-of-sight/out-of-mind. The execution is shockingly simple. If you think it's "all that hassle" I guarantee y…

You're a professional plumber working on hundreds of households saying it's shockingly simple and should take no time at all for a first time home owner to fix their own plumbing. You've already got the knowledge, experience, and tools/parts in the van - of course you don't think it's a hassle!

To be reasonably fair Lets Encrypt makes it easy. I even have a $5 a year shared hosting account that gives me Lets Encrypt SSL certs through cpanel. I can't imagine this feature is unique only to this one random shared hosting provider.

Re: Still Why No HTTPS?

#209

Post by exhilaration »

BrandoElFollito wrote: post #113

Because HTTPS is not as easy as HTTP. Sure there is Let's Encrypt and if you are facing Internet you are probably good to go. If you are on an internal network, then good luck. You need to build a PKI, and then put into your devices the right certificate so that it is trusted. If it was simpler, Apache would sing out its "It works!" in HTTPS and not HTTP.

So here's how I do it for internal network devices. I have a RaspberryPi running on 192.168.100.1 on my local network. On https://www.duckdns.org/ or whatever your favorite DNS provider is, I signed up for a free account and created myRaspberryPi.duckdns.org and pointed it to 192.168.100.1. While you're logged in, grab the DuckDNS API key.

Next you need to use ACME or Caddy (I use the latter) and tell it to do the Let's Encrypt DNS challenge using DuckDNS. It looks like this for Caddy:

    # in the Caddyfile
    tls {
        dns duckdns
    }

    # in the CaddyEnvfile
    DUCKDNS_TOKEN=your-api-key-goes-here
Then you start it like this: nohup caddy -http-port 80 -conf /etc/caddy/Caddyfile -envfile /etc/caddy/CaddyEnvFile -agree -email you@email.com &

That's it, now I can go to https://myRaspberryPi.duckdns.org and I've got HTTPS on my local network without anything exposed on the internet EXCEPT my device's internal IP. You've got to evaluate how much of a threat that is.

Re: Still Why No HTTPS?

#210

Post by lixtra »

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…

> Realistically you can't entirely deconflict these names. So you always have a risk of shadowing names from the public Internet.

It's totally save and legitimate for ycombinator to use secret.ycombinator.com on their intranet without telling anything about it to the outside internet.

Post reply on HN