Earlier quoted context omitted.
How do you use public Wi-Fi with captive portals?
You just don't.
Still Why No HTTPS?
101–110 of 345 posts
Re: Still Why No HTTPS?
#102Lots of US sites on their NO HTTPS list come up in Safari as HTTPS. Rutgers.edu for example.
Re: Still Why No HTTPS?
#103Earlier quoted context omitted.
To quote the link in my reply to you: > Buypass Go SSL > It is free! Issued in Scandinavia based on the industry standard ACME. I posted a diff showing the patch you can use to switch go's crypto/acme/autocert to use it. The CA does sell paid SSL product, but they also have a free ACME endpoint that issues 6 month certs. Here is an example of what one of the certs look like: https://crt.sh/?id=2075589060
It is free! Something might be free there. But not the wildcard certs we are talking about.
Re: Still Why No HTTPS?
#104I have a reason not to use https. I host a single site on a host (so, no login, subject name or path information to leak), which only contains details how to connect to my irc server at the same address. If the message is altered then the most pain anyone will have is connecting somewhere else for the first time. (They won’t be automatically logging in if they’re using this page). Why does everything need to be TLS?…
If the message is altered then the most pain anyone will have is connecting somewhere else for the first time If the page is altered so it loads 3rd party tracking code, then the pain is to be tracked. If the page is altered so it opens a "Please enter your ebay login" phishing site in the background, a user might switch tabs, think "Oh, I logged out of ebay somehow" and enter their password into the attackers site.…
Re: Still Why No HTTPS?
#105The biggest problem with forcing everything HTTPS is a false sense of security & trust that this gives to none-techie users. Security of the data transfer layer does not mean can or should trust the website you are visiting. Just because a website has a padlock does not mean it is trust worthy and you can hand over your CC details. https://www.amazon.somethiing.other.co/greatDiscount may look great to some!
Re: Still Why No HTTPS?
#106The biggest problem with forcing everything HTTPS is a false sense of security & trust that this gives to none-techie users. Security of the data transfer layer does not mean can or should trust the website you are visiting. Just because a website has a padlock does not mean it is trust worthy and you can hand over your CC details. https://www.amazon.somethiing.other.co/greatDiscount may look great to some!
http: insecure and https: secure
probably only when http ceases to exist can we start differentiating between trustworthy and untrustworty.
how we actually do that is something we still need to figure out.
for now we have a check against sites that are known to distribute malware. maybe we need to somehow track which sites are known to be trustworthy.
different factors can go into that. their privacy statement, past incidents and their response. etc...
Re: Still Why No HTTPS?
#107Earlier quoted context omitted.
I run https://github.com/joohoi/acme-dns to solve the wildcard domain problem. You can run it yourself locally, or trust (why?) the upstream's service.
Can you run it locally on your laptop? I think you still need a steady hostname pointing to it, right?
Re: Still Why No HTTPS?
#108Earlier quoted context omitted.
Maybe you saw this, but you can make _acme-challenge.domainA.tld a CNAME to _acme-challenge.domainB.tld. Where domainB is a throwaway domain used only for validation. There are some TLDs that are pretty cheap per year.
That might be a step forward. Still a bit complex, but maybe worth considering. Would that work for mulitple domains? So I CNAME the _acme-challenge subdomain for all my domains to _acme-challenge.cheapthrowaway.com?
And then have your acme client auth against that one.
No need for a new domain.
Re: Still Why No HTTPS?
#109Earlier quoted context omitted.
Though I'm on the "encrypt all the things!" camp, let me play devil's advocate for a moment. If I set up a purely static HTTP-only site in 1998, it would still work with today's browsers, more than 20 years later. If I set up a purely static HTTPS-only site in 1998, and didn't follow the upgrade treadmill, it would have stopped working for modern browsers some time ago.
Even with a static HTTP-only website, there's tons of stuff that you have to update anyway. Hardware gets outdated and needs replacing, at which point you cannot postpone the kernel update anymore because you need the new device drivers, etc. etc. You also don't want to stop updating your HTTP server, CVEs get discovered quite frequently. You can of course draw a line between that churn and the churn of updating your…
Irrelevant. Low traffic static website.
> at which point you cannot postpone the kernel update anymore because you need the new device drivers, etc. etc
Irrelevant as I didn't upgrade the hardware
>You also don't want to stop updating your HTTP server, CVEs get discovered quite frequently
it's a server for serving a single static page from 1998, nothing bad will happen if that machine is compromised, well, nothing worse that what could be done for not having HTTPs
Re: Still Why No HTTPS?
#110Because 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…
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 without any need for credentials for the actual domain.tld zone.
I use this currently with my own kuschku.de domain, you can check it out.
dig +trace @8.8.8.8 _acme-challenge.kuschku.de ANY