20 ms·

Still Why No HTTPS?

224 points by andimm 7y ago

wojciechpolak 7y ago
"gnu.org" is on the list marked as a Chinese website...
- k33l0r 7y ago
  There are some other confusing ones as well. nature.com is marked as Chinese, as are nginx.org and ntp.org. example.com is Indian in the list as is the now defunct dmoz.org. I don't understand the methodology behind the country assignments at all…
  - signed0 7y ago
    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?
    - deleted 7y ago
      [deleted]
    - lorenzhs 7y ago
      Same with w3.org, which is fifth on the list, and ebay-kleinanzeigen.de. Seems like quite a few entries are off.
      - chuckhoupt 7y ago
        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.
        jcranmer 7y ago
        Except the standards org that defines HTTP is the IETF, not the W3C...
        chuckhoupt 7y ago
        Opps! You're right, the W3C only helped author it. I was also wrong to say that w3.org never redirects to HTTPS. If the browsers sends a Upgrade-Insecure-Requests HTTP-header, then it redirects. That allows it to support all browsers as securely as possible. Sites like whynohttps.com and observatory.mozilla.org should really test for this pattern.
    - squiggleblaz 7y ago
      Yes, senate.gov in particular: % curl -I senate.gov HTTP/1.1 301 Moved Permanently Server: AkamaiGHost Content-Length: 0 Location: http://www.senate.gov/ http://www.senate.gov/ Date: Tue, 17 Dec 2019 10:37:04 GMT Connection: keep-alive % curl -I www.senate.gov HTTP/1.1 301 Moved Permanently Server: Apache Location: https://www.senate.gov/ https://www.senate.gov/ Content-Length: 231 Content-Type: text/html; charset=iso-8859-1 Date: Tue, 17 Dec 2019 10:37:08 GMT Connection: keep-alive It seems to meet the requirement for exclusion from the list. Data updated 16 Dec 2019, so I don't think it's stale. I've also checked from Australian and a European connection, so I don't think it's a regional thing. The other genuis.com doesn't work for me, the other sites redirect and set a cookie.
      - michaelt 7y ago
        If you're trying to get senate.gov onto the HSTS preload list, you have to redirect http://senate.gov http://senate.gov to https://senate.gov https://senate.gov before https://www.senate.gov https://www.senate.gov Maybe their tester applies the same criteria - although to me that feels a bit unfair...
    - shakna 7y ago
      It takes multiple redirects to reach https for several of those. It may just be looking at the first hop - which makes a certain sort of sense.
      - rocqua 7y ago
        Article states they allow multiple 301 or 302 redirects. What is not allowed are JS based redirects. There might also be a limit to the number of redirects followed, but that isn't mentioned in the article.
  - bcaa7f3a8bbc 7y ago
    I noticed it as well. I first thought it was a result of using CDN services or recycled IP addresses, but gnu.org doesn't use a CDN, and its IPv4 and IPv6 are both served by Hurricane Electric, which never did any business in mainland China. Must be a bug.
cassianoleal 7y ago
I mostly have port 80 egress traffic blocked on Little Snitch. The web is painful to use like that but gives you an idea of the sorry state of websites. A lot of websites just don't serve over HTTPS, or serve them with domains whose CN or SAN don't match the host. Many that do support https have links that downgrade you back to http on the same domain.
- dijit 7y ago
  How do you use public Wi-Fi with captive portals?
  - ninkendo 7y ago
    Allowing http://captive.apple.com http://captive.apple.com should make macOS’s captive portal auth window work.
    - Liquid_Fire 7y ago
      Most captive portals I've seen use HTTP redirection to the actual domain of the captive portal, so it would still fail as soon as it follows the redirected URL.
    - Zarel 7y ago
      If you block port 80, you'll never get to the part where you do URL filtering in the first place. (And also the redirection thing.)
      - deleted 7y ago
        [deleted]
      - ninkendo 7y ago
        I mean whitelist port 80 for captive.apple.com. Sorry if that wasn't clear. macOS has a background daemon which automatically hits captive.apple.com on connection to a WiFi network, to detect if it's behind a captive portal (and opens up a browser window to let you complete the flow, if it gets a 302). So that much should work even if you block egress port 80 but whitelist captive.apple.com. ...that is, assuming the portal to which you get redirected would be served over https, but I guess that isn't a given either.
WilliamEdward 7y ago
Some websites adamantly insist they did not need HTTPS because they are purely static. https://www.troyhunt.com/heres-why-your-static-website-needs-https/ https://www.troyhunt.com/heres-why-your-static-website-needs... The same website to my surprise has an article on why this is faulty reasoning.
- enriquto 7y ago
  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.
  - jmkni 7y ago
    Got a link? I'd like to see this sand castle :-)
  - AndrewStephens 7y ago
    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 blame you for not securing the area and double-checking the contents before inviting people. Even if I didn't blame you, I probably wouldn't respond to another invitation.
    - AnIdiotOnTheNet 7y ago
      > and then when I got there the sandcastle was actually a robot that stole my credit card. What kind of moron shows up to see a sandcastle and doesn't think twice about handing over their credit card?
megous 7y ago
Service workers are a poor replacement for the shared HTTP cache, since the cache will not be shared among users.
- snek 7y ago
  I apologize for not having a source, but browsers are actually looking into disabling shared caches between sites because of side-channel attacks.
ktpsns 7y ago
Because frankly, I neither trust letsencrypt nor the certificate authority system in general. This might prevent eavesdropping in your coffee shop wifi, but won't help against industrial spionage powered by three-letter-agencies who probably control some of these authorities.
- peterwwillis 7y ago
  This feels a bit like saying, I'm not going to use a traditional wood beam and shingled roof for my house, because it won't help against a meteor.
- minitech 7y ago
  So because you think it’s not a good enough defense against three-letter agencies, you’ll let everyone else continue to eavesdrop too? Controlling a CA isn’t even enough to strip confidentiality, there needs to be an active (private keys!) and ideally public (certificate transparency, CAA) attack on top of that that entities who can pull it off definitely won’t want to waste.
peterwwillis 7y ago
Recently an OpenShift cluster I admin went down because of long-lived certs not being rotated in time. There are many clients, servers, nodes, services, and configs involved, so rotating is non-trivial, so of course it's automated, and of course because it's not tested regularly, the automation just doesn't work after a while. Using the automation only seems to make things worse, and getting everything working again ends up taking days. PKI is technically the best practice for these systems, but it's also the most fragile and complicated. At a certain point, if the security model is so complex that it becomes hard to reason about, it's arguable that it's no longer a secure model, to say nothing of operational reliability. I also have a whole rant about how some business models and government regulations literally require inspecting TLS certs of critical transport streams, and how the protocols are designed only to prevent this, and all the many problems this presents as a result, but I don't think most people care about those concerns. Oh, and gentle reminder that there are still 100% effective attacks that allow automated generation of valid certs for domains you don't control. It doesn't happen frequently (that we know of) but it has happened multiple times in the past decade, so just having a secure connection to a website doesn't mean it's actually secure.
greggman2 7y ago
what is about that site's low contrast. My eyes can barely focus
veb 7y ago
I don't get it. With Lets Encrypt, it's like one or two lines to get everything set up. I'm guessing people aren't as lucky as I am to be running on newer machines and such. I mean it even edits your nginx files to redirect http to https if you agree. It's not hard.
- onion-soup 7y ago
  Nope, it is not straight-forward and still a confusing process.
  - chungy 7y ago
    Instructions are here: https://certbot.eff.org/ https://certbot.eff.org/ I don't know how it could possibly be any simpler.
    - onion-soup 7y ago
      While I appreciate the efforts of certbot to make it as user-friendly as possible I still find this state of things unforgivable. I don't know where it went wrong so that today a developer must spend time learning and tweaking a low-level encryption tools. I'm just saying https will never be 100% unless it becomes a baked-in feature of any hosting.
      - cm2187 7y ago
        Starting with baking ACMEv2 in the major webservers (apache, IIS, etc).
        deleted 7y ago
        [deleted]
        Jaruzel 7y ago
        If Microsoft baked in Auto-cert-install in to IIS that allowed you to cherry pick a provider, and/or just select their own free CA, that'd really solve the problem for Windows based web servers. In my experience CertBot/ACME type renewal doesn't work reliably for Windows/IIS.
onion-soup 7y ago
Because it's always pain in the ass to set it up and then renew?
- susam 7y ago
  I have found that Let's Encrypt certbot makes it really simple to set up HTTPS and renew the certificate for simple websites. Examples for Nginx: - Setup: https://github.com/susam/susam.in/blob/master/Makefile#L30-L31 https://github.com/susam/susam.in/blob/master/Makefile#L30-L... - Renewal: https://github.com/susam/susam.in/blob/master/etc/crontab#L1 https://github.com/susam/susam.in/blob/master/etc/crontab#L1
- watermelon0 7y ago
  How exactly is it a pain in the ass? - If you are hosting a simple static page or blog, your hosting provider probably has Let's Encrypt plugin. - If you have your own VPS, Caddy has you covered with file serving, fastcgi support for PHP, and proxying to (g)unicorn/nodejs/Go/.NET, and has HTTPS enabled by default. - If you have more advanced setup (e.g. containers), traefik supports HTTPS with just a few lines of configuration. - If you are big enough to afford cloud, it takes a few lines of Terraform code to provision certificate for load balancers (speaking for AWS, and assuming others have similar solutions). For other cases (e.g. lots of traffic with custom haproxy/nginx/etc. setup), you are probably smart enough to find out how to enable Let's Encrypt support.
  - at_a_remove 7y ago
    1) Not everything is running bare Apache. In fact, some services might have some rather strange web-driven GUI (or, more interestingly, curses-like) that requires you to carefully load a certificate, a CSR, and so forth in a somewhat arcane manner. Some pretty niche serving exists out there and I have had to deal with a bunch of them, to the point where I had to write extensive documentation on keeping the certificates up to date on each separate weird service. Many of these services have a "no user-servicable parts inside, your warranty will be voided ..." clauses in the service contract which deter spelunking. 2) Some services require wildcards, like proxies. 3) Some organizations have, due to someone far away making strange decisions, policies about certificate authorities, and people to audit for compliance. Therefore, a cert costs money and, for a site which is purely informational, that's a hard sell. 4) Because we're not running on a hosting provider, a VPS, containers, or cloud. 5) Because not everyone wants to deal with some combination of the above every three months due to Let's Encrypt's expiration policy.
cm2187 7y ago
Is it still the case that when you think you connect in https to a website, only the segment to cloudflare is encrypted and the segment cloudflare to the web server might not be?
- thenewnewguy 7y ago
  Depends on the website's Cloudflare configuration. Cloudflare supports both methods - CF to website can be HTTP or HTTPS.
- mtberatwork 7y ago
  Yes, that's SSL termination. Generally this happens at the CDN, load balancer or proxy (e.g. nginx used as a cache) layer and is pretty common since the fleet of servers handling the request after being routed are in a private network. With CF, the request from CF to the origin is over a public network and it will depend on how the user has configured their CF setup as to whether or not that hand-off is then encrypted. If they are doing SSL termination in CF, then it won't be encrypted from CF to the origin server.
- slig 7y ago
  Yes, it's called "flexible SSL".
namibj 7y ago
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.
- Sukera 7y ago
  Do you have a source on that? Quite a few people seem to disagree: https://istlsfastyet.com/ https://istlsfastyet.com/
  - deleted 7y ago
    [deleted]
  - namibj 7y ago
    Oh, yeah, for good clients it's totally fine. But e.g. a machine I'll try an http benchmark on in a couple hours (2 cires; 4780 BogoMIPS each) only managed 4177 ops/s using the fastest-available curve X25519 with openssl speed ecdh gatling -V -n -p 80 -u nobody I know this is somewhat extreme, but on a cpu that was about 30% faster I got 40k rps for small files using the kernel's loopback, which is where the cpu spent most of it's time. Feel free to try.
    - dependenttypes 7y ago
      This should happen only during the handshake though.
  - kevingadd 7y ago
    In my testing for high-throughput scenarios like copies over ssh/rsync/https/smb (i tried them all) in every case encryption was a big hit to throughput. hardware assistance (built into the CPU) helped a lot but it was still a massive boost to shut off encryption - saving literal minutes on every bulk transfer, multiple transfers per day. For the average case it probably doesn't matter, and you can optimize it, but I think it is totally understandable that the average novice could end up with bad https performance if only because the defaults are bad or they made a mistake. If hardware assist for the handshake and/or transfer crypto is shut off (or unavailable, on lower-spec CPUs) your perf is going to tank real hard. I ended up using ssh configured to use the weakest (fastest) crypto possible, because disabling crypto entirely was no longer an option. I controlled the entire network end to end so no real risk there - but obviously a dangerous tool to provide for insecure links. Also worth keeping in mind that there are production scenarios now where people are pushing 1gb+ of data to all their servers on every deploy - iirc among others when Facebook compiles their entire site the executable is something like a gigabyte that needs to be pushed to thousands of frontends. If you're doing that over encrypted ssh you're wasting cycles which means wasting power and you're wasting that power on thousands of machines at once. Same would apply if the nodes pull the new executable down over HTTPS.
Thorrez 7y ago
The article says googletagmanager.com has HSTS preloading. But it doesn't. This is easily testable. I view the website in both Chrome and Firefox, and it's http, not https. Sure googletagmanager.com is in the preload list, but it doesn't have "mode": "force-https". It just has certificate pinning, not HSTS.
founderling 7y ago
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 letsencrypt should allow wildcards to the owner of somedomain.com without dabbling with the DNS. The way things are now, I don't use ssl for my smaller projects at smallproject123.mydomain.com because I don't want the hassle of yet another cronjob and I sometimes don't want the subdomain to go into a public registry (where all certificates go these days).
- benjojo12 7y ago
  There is a 2nd ACME free CA these days based in Norway: https://www.buypass.com/ssl/products/acme https://www.buypass.com/ssl/products/acme I used it on a pervious post to test it out and it seemed to be fine: https://github.com/benjojo/you-cant-curl-under-pressure/commit/eb163fc4dfef34760ff68be13e8ce88d78f6c017 https://github.com/benjojo/you-cant-curl-under-pressure/comm...
  - founderling 7y ago
    Did you miss the "free" in my comment or am I missing something?
    - benjojo12 7y ago
      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 https://crt.sh/?id=2075589060
      - tyingq 7y ago
dijit 7y ago
I 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? It feels like a cargo cult. A requirement: “because!” In other scenarios it’s worth modelling threats and I agree that it’s good to err on the side of caution but aside from the modification of my connection information there’s no good tangible reason to incur an overhead in administration. Although it should be noted; part of the reason that web server even exists is to do letsencrypt for a globally geobalanced irc network.
- founderling 7y ago
  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. Exposing them to the pain of ecommerce fraud. If the page is altered to use a 0-day exploit, the pain is to have a zombie machine afterwards. Etc etc ...
  - dijit 7y ago
    If you can inject such content (as in an arp poisoning or other man in the middle scenario) why wouldn’t you go after the dns requests?
    - Liquid_Fire 7y ago
      HTTPS will protect you against hijacked DNS requests as well.
      - dijit 7y ago
        Not by itself, if you have special HTTP headers it will. But some of those are deprecated (HPKP; for example)[0] [0]: https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning#Browser_support_and_deprecation https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning#Browse...
dvfjsdhgfv 7y ago
HTTPS is not an obligation. Most people believe it's a must these days, but it's not. There is a nice rebuttal of Troy's arguments on N-gate (via webcache as direct links from HN end up in an endless pseudo-captcha): http://webcache.googleusercontent.com/search?q=cache:t_oVSNuTvIgJ:n-gate.com/software/+&cd=1&hl=en&ct=clnk&gl=pl http://webcache.googleusercontent.com/search?q=cache:t_oVSNu...
edf13 7y ago
The 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 https://www.amazon.somethiing.other.co/greatDiscount may look great to some!
- minitech 7y ago
  This is exactly the opposite of a forcing HTTPS problem. When HTTPS isn’t everywhere, HTTPS gives a false sense of security. When it is, browsers can stop emphasizing it. We’re already well down that path, with padlocks no longer being green/being hidden entirely, EV certificates losing their confusion vector, insecure pages being assigned the icon that sticks out…
- LeonM 7y ago
  I think that was the main reason why browser vendors moved away from the green padlock symbol.
- seqastian 7y ago
  > The biggest problem with forcing everything HTTPS No it isn't. Https not being 100% bulletproof is unrelated to using it everywhere. And it's lightyears away from its biggest problem.
- em-bee 7y ago
  true but the only way to get there is to force http into oblivion. right now people think: 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...
- simias 7y ago
  If we migrate to HTTPS everywhere we can get rid of HTTP for general use and switch to a different UI, where HTTPS websites don't have any special icon but HTTP ones get a warning icon. It's already effectively how password form submissions work in many browsers.
altmind 7y ago
Preloads list is an absolute kludge that does not and will never scale and creates a huge deal of problems and works only for specific browsers. The task is not as simple as using DNS to store strict https flags(as DNS can be manipulated by intermediary), but hardcoding the lists in the browsers and keeping the lists in the chrome's code is definitely not a solution.
- kuschku 7y ago
  The goal is to slowly move higher levels into that list. e.g. in the past it was just domains and subdomains. Today there are already some TLDs on the list themselves.
- Avamander 7y ago
  The solution is to make the default connection port 443 HTTPS and allow people to drop listening on port 80.
SlowRobotAhead 7y ago
Am I missing something? Lots of US sites on their NO HTTPS list come up in Safari as HTTPS. Rutgers.edu for example.
davidmurdoch 7y ago
One potentially good reason to not force SSL: https://meyerweb.com/eric/thoughts/2018/08/07/securing-sites-made-them-less-accessible/ https://meyerweb.com/eric/thoughts/2018/08/07/securing-sites... TL;DR: Secure websites can make the web less accessible for those who rely on metered satellite internet (and I'm sure plenty of other cases).
- satanspastaroll 7y ago
  Trading security for convenience is rarely a good idea. The rest of the world should not conform the to failures of certain areas to provide internet.
  - oneeyedpigeon 7y ago
    No, but it's a good idea to have the option, so long as people are aware of the implications.
  - rkagerer 7y ago
    Unfortunately convenience usually does tradeoff against security. Thoughtful UX can deliver both, but it's rare to find in practice. That casual dismissal of davidmurdoch's counterargument comes across tone-deaf to people stuck on crappy connections.
  - davidmurdoch 7y ago
    I see your point. But we trade security for convenience 24/7/365. We could all have bulletproof glass in our homes, personal security cameras everywhere, backup generators, panic rooms, etc, but we don't, because it's not convenient (and I know the expense is primarily what makes it not convenient, but I think it's still a valid argument). Providing access to Wikipedia over http to people in third world countries may be worth the risk of someone MITMing the site with propaganda. The suggestion is only to give some users the option.
    - pixl97 7y ago
      Mitm with propaganda is the least of the worries. Full on exploit code is. The fact is as an ecosystem develops completely increases. Lifeforms in that ecosystem have to spend more time and effort protecting themselves from outside attacks as time progresses.
BrandoElFollito 7y ago
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.
- zurn 7y ago
  Let's Encrypt works on internal networks too. Fun fact: TLS doesn't require certificates, and some browsers even used to support HTTPS in these TLS modes many moons ago. See eg https://security.stackexchange.com/questions/23024/can-diffie-hellman-anonymous-be-used-as-a-cipher-for-ssl-for-one-way-certifiate#23025 https://security.stackexchange.com/questions/23024/can-diffi...
  - BrandoElFollito 7y ago
    Ah? That's good to know! How to set this up on a domain which is not connected to Internet? How is the check done?
    - benoliver999 7y ago
      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).
      - BrandoElFollito 7y ago
        The problem is that I also have domains which are completely internal, not known/resolvable outside
        cheschire 7y ago
        Could you run an internal CA server instead of self signing? At least then you reduce your attack surface if you’re compromised internally.
faissaloo 7y ago
Because even Certbot is a massive pain to setup if you're not using a very generic setup
dm33tri 7y ago
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.
- couchand 7y ago
  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.
  - dm33tri 7y ago
    You can't assume protection, whereas with http you assume no protection. So, if you can't trust certificate (not when it is invalid), just show same level of protection as http.
    - zozbot234 7y ago
      The problem is that a http: protocol specifier implies no protection; the moment you follow the link, you know that the connection is not secured. Whereas a self-signed https: connection could be due to someone MITM'ing a site that generally uses CA's, in which case "no warning message" implies that the site is secured. The browser message has to make it clear to the user that something possibly unexpected is going on.
  - deleted 7y ago
    [deleted]
  - JackRabbitSlim 7y ago
    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.
    - arminiusreturns 7y ago
strenholme 7y ago
One annoyance with this system, from the linked webpage: >an expectation that a site responds to an HTTP request over the insecure scheme with either a 301 or 302 Doing things this way is the final nail in the coffin for Internet Explorer 6, since IE6 does not use any version of SSL which is considered secure here in 2019. And, yes, I have seen in people the real world still using ancient Internet Explorer 6 as recently as 2015, and Windows XP as recently as 2017. Which is why I instead do the http → https redirection with Javascript: I make sure the client isn’t using an ancient version of Internet Explorer, then use Javascript to move them to the https version of my website. This way, anyone using a modern secure browser gets redirected to the https site, while people using ancient IE can still use my site over http. (No, I do not make any real attempt to have my HTML or CSS be compatible with IE6, except with https://samiam.org/resume/ https://samiam.org/resume/ and I am glad the nonsense about “pixel perfect” and Flash websites is a thing of the past with mobile everywhere)
- namibj 7y ago
  Be aware that blocking scripts from insecure connections is something you'd usually want to do...
  - strenholme 7y ago
    “usually” being the operative word. I’m not quite ready to throw IE6 (Internet Explorer 6) and all http-only browsers completely under a bus yet.
- Wingy 7y ago
  Why not look at the User-Agent header and 301 to https if you don't see IE6?
  - strenholme 7y ago
    That’s actually a good idea. It was simpler to set up the Javascript redirect. It I were to go that way, I would probably redirect IE6 to a “neverssl” subdomain (which also would be useful for dealing with WiFi capture portals).
andrewfromx 7y ago
i still use https://neverssl.com https://neverssl.com daily. I hope it never goes away.
- IggleSniggle 7y ago
  Wow that's pretty interesting! Thanks for sharing.
- nhumrich 7y ago
  Intentional that your link is https?
  - andrewfromx 7y ago
    ha, no i think HN did that automatically? I wrote http without s
fiatjaf 7y ago
Because it's hard and a pain. Sure, depending on your setup it's easy, but for a lot of setups it isn't. Instead of trying to say HTTPS is easy and shame everybody who isn't doing it more efforts should be diverted into creating an actual fully encrypted network that doesn't need CAs.
- fiatjaf 7y ago
  What actually happens when you try to force HTTPS over the internet: you centralize it, you make it harder for the small player, hobbyist, personal homepage guy, and make it easier for the big corporation.
forgottenpass 7y ago
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.
netsectoday 7y ago
Without HSTS preload anyone on your local network can arp/dns spoof your traffic, MITM you, and automatically inject malicious javascript (cryptominers, credential-stealers, etc.), access all of the page content, and manipulate the page or response. If you are connecting to a "Free Public WiFi" and the malicious actor is the one broadcasting the access-point; it's even easier to MITM you. Without Cert & Key Pinning your employee laptop can be MITM by corporate to eavesdrop on all of your HTTPS traffic. The browser will show that the connection is secure, but it isn't. When you pin the cert and key - even with a compromised corporate computer - the insecure site warning will show and you'll be alerted to the fuckery. > Doing things this way is the final nail in the coffin for Internet Explorer 6 - Fucking great! Nothing else to say here. > handshakes take enormous amounts of CPU - This is vastly overstated (enormous?). Also, this is called a tradeoff. Security isn't free in time, money, or performance. > Preloads list is an absolute kludge that does not and will never scale... and works only for specific browser - The preload list, right now, is 10.6mb and contains 90,862 entries. This seems to function and scale just fine. Seeding your browser with known values is really the best way to do this until 99.X% of web traffic is provided over HTTPS... Also Chrome, Firefox, Safari, IE/Edge, and Opera make up 98% of all browser traffic today and they have all supported this standard for years. > The biggest problem with forcing everything HTTPS is a false sense of security. - Defense in depth. Layering security controls is the only way to go. Also; this is some crazy mental gymnastics to take the position "wearing a seatbelt is a false sense of security because you can still crash". > Because it's hard and a pain. - Feeling that pain is offset onto the attackers trying to compromise your site. If you don't feel the pain; they don't either. > Secure websites can make the web less accessible for those who rely on metered satellite internet... TLS 1.3 with 1-RTT should improve this situation. - Even if your entire business depended upon delivering data to metered satellite internet users; the risk outweighs the cost when not encrypting your traffic. WARNING: DON'T IMPLEMENT 0-RTT OR 1-RTT WITHOUT UNDERSTANDING YOUR APPLICATION-SPECIFIC REQUIREMENTS. You can really fuck this up by not properly managing tokens between your webserver and application layer. Not recommended. > I don't get it. With Lets Encrypt, it's like one or two lines to get everything set up. - True, but it get's confusing really fast if you don't 100% match the certbot use-case. > HTTPS is not an obligation. - For 99% of people running businesses; it is. > Recently an OpenShift cluster I admin went down because of long-lived certs not being rotated in time. - If you have had certbot running for a long time I would suggest you check your server logs TODAY and make sure your cron job is still working correctly. Recently there was a change with the certbot acme version requirement and your reissue might be failing. Seriously, take a quick look right now. > Because frankly, I neither trust letsencrypt nor the certificate authority system in general... but won't help against industrial (e)spionage - Places tinfoil hat on... you're not wrong.
z3t4 7y ago
Had to access an EOL device and couldn't browse the web because of all ended certificates...
jzl 7y ago
I clicked through to the list of sites. Embarrassing to see that mit.edu is not https by default! The same institution invented Kerberos. Come on MIT, fix this please.
bo1024 7y ago
Maybe I’m wrong, but I feel SSL has a downside of relying on more centralization. If a visitor to my totally-static webpage wants to bypass that layer and request the http version directly, I’m going to let them. (Obviously not excited about the idea of being mitm’d but it’s not a security risk, so leave that tradeoff up to the visitor).
- pornel 7y ago
  https://doesmysiteneedhttps.com/ https://doesmysiteneedhttps.com/ MITM can do anything to your site, so your totally-static site may not be static any more at the victim's end. It may be a site collecting private details, attacking the browser, or using the victim to attack other sites. Your static HTTP site is a network vulnerability and a blank slate for the attacker.
  - anony121212 7y ago
    So then disable javascript for http sites
    - Sohcahtoa82 7y ago
      That won't do anything. If someone can Man-in-the-Middle you, then they can easily forge a 302 redirection to a malicious web page that could be HTTPS.
    - pixl97 7y ago
      Ok, cool, I found a new numerical overflow image rendering in your browser library. Now I can shove an <img> tag in the insecure stream and exploit you.
  - bo1024 7y ago
    Thanks for the reply. I've seen that site but it seems to be aimed at people who don't offer any https at all. At this point I'm still more comfortable offering visitors the decision. (Not many people visit my site by the way.)
bullen 7y ago
Downvote time: Why HTTPS? I made my own security: http://talk.binarytask.com http://talk.binarytask.com
- DuskStar 7y ago
  Do you have a description of how you made your own security and what it provides?
  - bullen 7y ago
    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".
    - necovek 7y ago
      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 you using self-signed certs, and likely even worse because there are more attack vectors even outside the initial connection.
      - bullen 7y ago
        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!!!
anony121212 7y ago
Ability to write my own HTTP server from scratch. Content is for downloading and use offline.
LinuxBender 7y ago
It isn't just web sites. Many software repos still use http or native rsync. Some would argue that you validate the packages with GPG, but you would be amazed if you saw how many people install the GPG public key from the same mirror they download software from.
- surge 7y ago
  Gradle, granted they're fixing it. https://blog.gradle.org/decommissioning-http https://blog.gradle.org/decommissioning-http
vivekd 7y ago
One thing that surprised me was how hard it was to set up https https redirects for websites on aws and Google cloud. I needed too set up a load balancer to do https. The redirects are also hard, I have a static site using Google storage and I have to create a server instance and redirect from there because it's not possible to do an automatic redirect. I don't know why the big cloud hosting providers aren't cooperating to make full https implementation easier.
gmiller123456 7y ago
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.
- pixl97 7y ago
  Um, the number of people connected to my ssh server I can count on my fingers, and generally have communicated with beforehand. The number of people communicating with my https server is one larger than I could ever count to monitonically. If you dont get the difference in scale between the two you might have an issue understanding the real problem.
- xvector 7y ago
  > 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. Genuinely curious - what alternatives do you have in mind? Are there any WoT models that interest you more? > There is currently only one free cert provider, if there are ever issues with it, your users will see a scary error message Isn't this the point? > Downloading and running code from a 4th, or 5th party and giving it access to your config files is not "more secure". Could you elaborate? Have you written your whole stack from scratch? You are running millions of lines of code that you will never read but have been implemented by other parties. > HTTPS is needlessly complex making it hard to implement. Isn't this done with robust battle-tested libraries and built-in support in modern languages? --- Mainly I'm just wondering why you're letting perfect be the enemy of good. There's always room for improvement in everything, but I don't think user privacy is a reasonable sacrifice to make. > Giving in ends the hope that it will ever get changed. Abstaining from HTTPS won't be seen by anyone as a protest, but as incompetency, whether you find that justifiable or not.
mohas 7y ago
Many of us have to host our websites on shared hosts that does not support HTTPS freely, HTTPS costs money in the third world
necovek 7y ago
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 unavailable. Sure, some sites have broken https endpoints, but browsers have enforced crazier shit recently.
- discreditable 7y ago
  Annoyingly, if you want to get a let's encrypt cert you have to serve http. Back when I was manually purchasing & installing certs I didn't even listen on 80 for several services. (Exception being if you use the dns challenge)
  - vunie 7y ago
    >(Exception being if you use the dns challenge) Exactly. DNS challenges don't suffer from this issue.
- kuschku 7y ago
  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 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.
  - necovek 7y ago
    Right, so HSTS will protect a visitor who has visited your web site at most max-age ago using that particular browser and device. Or, as I stated, for preload, you have to either not have HTTP at all, or have a redirect to HTTPS: it should be clear from my above post why I think a redirect is a bad idea. I also dislike turning off HTTP for those that don't have any other option. To me it seems that browsers just switching to https-by-default and http-as-fallback is a much simpler, better, backwards-compatible change that should just work. What am I missing and why do you feel HSTS is a good idea compared to that?
printercenter 7y ago
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-message/ https://printerhelpcenter.com/replace-brother-drum-error-mes... https://printerhelpcenter.com/how-to-fix-canon-printer-error-b200/ https://printerhelpcenter.com/how-to-fix-canon-printer-error...
romwell 7y ago
I consider myself young, but I've been around long enough to to rely on One True Service Provider for anything. And "Let's Encrypt" is not an answer to "HTTPS is not free". It's not. We all are going to see our projects outlive Let's Encrypt (or their free tier). In the end, nothing is secure. A dedicated attacker will find a way, given enough resources. Any security measure is just a deterrent. My deterrent is that it's not worth MITM'ing my personal website with, like, 10 monthly visitors. (The reader might gasp that I lock my bicycle with a chain that can be snapped in a second, and that a strong enough human can probably bash my home door in). Anyway. It's almost 2020, and if you are still advocating on moving the entirety of the Web to reliance on Big Centrally Good Guys, I really don't know what else to say to you.

Still Why No HTTPS?

224 points by andimm 7y ago

wojciechpolak 7y ago

"gnu.org" is on the list marked as a Chinese website...

k33l0r 7y ago
There are some other confusing ones as well. nature.com is marked as Chinese, as are nginx.org and ntp.org. example.com is Indian in the list as is the now defunct dmoz.org. I don't understand the methodology behind the country assignments at all…
- signed0 7y ago
  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?
  - deleted 7y ago
    [deleted]
  - lorenzhs 7y ago
    Same with w3.org, which is fifth on the list, and ebay-kleinanzeigen.de. Seems like quite a few entries are off.
    - chuckhoupt 7y ago
      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.
      - jcranmer 7y ago
        Except the standards org that defines HTTP is the IETF, not the W3C...
        chuckhoupt 7y ago
        Opps! You're right, the W3C only helped author it. I was also wrong to say that w3.org never redirects to HTTPS. If the browsers sends a Upgrade-Insecure-Requests HTTP-header, then it redirects. That allows it to support all browsers as securely as possible. Sites like whynohttps.com and observatory.mozilla.org should really test for this pattern.
  - squiggleblaz 7y ago
    Yes, senate.gov in particular: % curl -I senate.gov HTTP/1.1 301 Moved Permanently Server: AkamaiGHost Content-Length: 0 Location: http://www.senate.gov/ http://www.senate.gov/ Date: Tue, 17 Dec 2019 10:37:04 GMT Connection: keep-alive % curl -I www.senate.gov HTTP/1.1 301 Moved Permanently Server: Apache Location: https://www.senate.gov/ https://www.senate.gov/ Content-Length: 231 Content-Type: text/html; charset=iso-8859-1 Date: Tue, 17 Dec 2019 10:37:08 GMT Connection: keep-alive It seems to meet the requirement for exclusion from the list. Data updated 16 Dec 2019, so I don't think it's stale. I've also checked from Australian and a European connection, so I don't think it's a regional thing. The other genuis.com doesn't work for me, the other sites redirect and set a cookie.
    - michaelt 7y ago
      If you're trying to get senate.gov onto the HSTS preload list, you have to redirect http://senate.gov http://senate.gov to https://senate.gov https://senate.gov before https://www.senate.gov https://www.senate.gov Maybe their tester applies the same criteria - although to me that feels a bit unfair...
  - shakna 7y ago
    It takes multiple redirects to reach https for several of those. It may just be looking at the first hop - which makes a certain sort of sense.
    - rocqua 7y ago
      Article states they allow multiple 301 or 302 redirects. What is not allowed are JS based redirects. There might also be a limit to the number of redirects followed, but that isn't mentioned in the article.
- bcaa7f3a8bbc 7y ago
  I noticed it as well. I first thought it was a result of using CDN services or recycled IP addresses, but gnu.org doesn't use a CDN, and its IPv4 and IPv6 are both served by Hurricane Electric, which never did any business in mainland China. Must be a bug.

cassianoleal 7y ago

I mostly have port 80 egress traffic blocked on Little Snitch. The web is painful to use like that but gives you an idea of the sorry state of websites. A lot of websites just don't serve over HTTPS, or serve them with domains whose CN or SAN don't match the host. Many that do support https have links that downgrade you back to http on the same domain.

dijit 7y ago
How do you use public Wi-Fi with captive portals?
- ninkendo 7y ago
  Allowing http://captive.apple.com http://captive.apple.com should make macOS’s captive portal auth window work.
  - Liquid_Fire 7y ago
    Most captive portals I've seen use HTTP redirection to the actual domain of the captive portal, so it would still fail as soon as it follows the redirected URL.
  - Zarel 7y ago
    If you block port 80, you'll never get to the part where you do URL filtering in the first place. (And also the redirection thing.)
    - deleted 7y ago
      [deleted]
    - ninkendo 7y ago
      I mean whitelist port 80 for captive.apple.com. Sorry if that wasn't clear. macOS has a background daemon which automatically hits captive.apple.com on connection to a WiFi network, to detect if it's behind a captive portal (and opens up a browser window to let you complete the flow, if it gets a 302). So that much should work even if you block egress port 80 but whitelist captive.apple.com. ...that is, assuming the portal to which you get redirected would be served over https, but I guess that isn't a given either.

WilliamEdward 7y ago

Some websites adamantly insist they did not need HTTPS because they are purely static. https://www.troyhunt.com/heres-why-your-static-website-needs-https/ https://www.troyhunt.com/heres-why-your-static-website-needs... The same website to my surprise has an article on why this is faulty reasoning.

enriquto 7y ago
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.
- jmkni 7y ago
  Got a link? I'd like to see this sand castle :-)
- AndrewStephens 7y ago
  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 blame you for not securing the area and double-checking the contents before inviting people. Even if I didn't blame you, I probably wouldn't respond to another invitation.
  - AnIdiotOnTheNet 7y ago
    > and then when I got there the sandcastle was actually a robot that stole my credit card. What kind of moron shows up to see a sandcastle and doesn't think twice about handing over their credit card?

megous 7y ago

Service workers are a poor replacement for the shared HTTP cache, since the cache will not be shared among users.

snek 7y ago
I apologize for not having a source, but browsers are actually looking into disabling shared caches between sites because of side-channel attacks.

ktpsns 7y ago

Because frankly, I neither trust letsencrypt nor the certificate authority system in general. This might prevent eavesdropping in your coffee shop wifi, but won't help against industrial spionage powered by three-letter-agencies who probably control some of these authorities.

peterwwillis 7y ago
This feels a bit like saying, I'm not going to use a traditional wood beam and shingled roof for my house, because it won't help against a meteor.
minitech 7y ago
So because you think it’s not a good enough defense against three-letter agencies, you’ll let everyone else continue to eavesdrop too? Controlling a CA isn’t even enough to strip confidentiality, there needs to be an active (private keys!) and ideally public (certificate transparency, CAA) attack on top of that that entities who can pull it off definitely won’t want to waste.

peterwwillis 7y ago

Recently an OpenShift cluster I admin went down because of long-lived certs not being rotated in time. There are many clients, servers, nodes, services, and configs involved, so rotating is non-trivial, so of course it's automated, and of course because it's not tested regularly, the automation just doesn't work after a while. Using the automation only seems to make things worse, and getting everything working again ends up taking days. PKI is technically the best practice for these systems, but it's also the most fragile and complicated. At a certain point, if the security model is so complex that it becomes hard to reason about, it's arguable that it's no longer a secure model, to say nothing of operational reliability. I also have a whole rant about how some business models and government regulations literally require inspecting TLS certs of critical transport streams, and how the protocols are designed only to prevent this, and all the many problems this presents as a result, but I don't think most people care about those concerns. Oh, and gentle reminder that there are still 100% effective attacks that allow automated generation of valid certs for domains you don't control. It doesn't happen frequently (that we know of) but it has happened multiple times in the past decade, so just having a secure connection to a website doesn't mean it's actually secure.

greggman2 7y ago

what is about that site's low contrast. My eyes can barely focus

veb 7y ago

I don't get it. With Lets Encrypt, it's like one or two lines to get everything set up. I'm guessing people aren't as lucky as I am to be running on newer machines and such. I mean it even edits your nginx files to redirect http to https if you agree. It's not hard.

onion-soup 7y ago
Nope, it is not straight-forward and still a confusing process.
- chungy 7y ago
  Instructions are here: https://certbot.eff.org/ https://certbot.eff.org/ I don't know how it could possibly be any simpler.
  - onion-soup 7y ago
    While I appreciate the efforts of certbot to make it as user-friendly as possible I still find this state of things unforgivable. I don't know where it went wrong so that today a developer must spend time learning and tweaking a low-level encryption tools. I'm just saying https will never be 100% unless it becomes a baked-in feature of any hosting.
    - cm2187 7y ago
      Starting with baking ACMEv2 in the major webservers (apache, IIS, etc).
      - deleted 7y ago
        [deleted]
      - Jaruzel 7y ago
        If Microsoft baked in Auto-cert-install in to IIS that allowed you to cherry pick a provider, and/or just select their own free CA, that'd really solve the problem for Windows based web servers. In my experience CertBot/ACME type renewal doesn't work reliably for Windows/IIS.

onion-soup 7y ago

Because it's always pain in the ass to set it up and then renew?

susam 7y ago
I have found that Let's Encrypt certbot makes it really simple to set up HTTPS and renew the certificate for simple websites. Examples for Nginx: - Setup: https://github.com/susam/susam.in/blob/master/Makefile#L30-L31 https://github.com/susam/susam.in/blob/master/Makefile#L30-L... - Renewal: https://github.com/susam/susam.in/blob/master/etc/crontab#L1 https://github.com/susam/susam.in/blob/master/etc/crontab#L1
watermelon0 7y ago
How exactly is it a pain in the ass? - If you are hosting a simple static page or blog, your hosting provider probably has Let's Encrypt plugin. - If you have your own VPS, Caddy has you covered with file serving, fastcgi support for PHP, and proxying to (g)unicorn/nodejs/Go/.NET, and has HTTPS enabled by default. - If you have more advanced setup (e.g. containers), traefik supports HTTPS with just a few lines of configuration. - If you are big enough to afford cloud, it takes a few lines of Terraform code to provision certificate for load balancers (speaking for AWS, and assuming others have similar solutions). For other cases (e.g. lots of traffic with custom haproxy/nginx/etc. setup), you are probably smart enough to find out how to enable Let's Encrypt support.
- at_a_remove 7y ago
  1) Not everything is running bare Apache. In fact, some services might have some rather strange web-driven GUI (or, more interestingly, curses-like) that requires you to carefully load a certificate, a CSR, and so forth in a somewhat arcane manner. Some pretty niche serving exists out there and I have had to deal with a bunch of them, to the point where I had to write extensive documentation on keeping the certificates up to date on each separate weird service. Many of these services have a "no user-servicable parts inside, your warranty will be voided ..." clauses in the service contract which deter spelunking. 2) Some services require wildcards, like proxies. 3) Some organizations have, due to someone far away making strange decisions, policies about certificate authorities, and people to audit for compliance. Therefore, a cert costs money and, for a site which is purely informational, that's a hard sell. 4) Because we're not running on a hosting provider, a VPS, containers, or cloud. 5) Because not everyone wants to deal with some combination of the above every three months due to Let's Encrypt's expiration policy.

cm2187 7y ago

Is it still the case that when you think you connect in https to a website, only the segment to cloudflare is encrypted and the segment cloudflare to the web server might not be?

thenewnewguy 7y ago
Depends on the website's Cloudflare configuration. Cloudflare supports both methods - CF to website can be HTTP or HTTPS.
mtberatwork 7y ago
Yes, that's SSL termination. Generally this happens at the CDN, load balancer or proxy (e.g. nginx used as a cache) layer and is pretty common since the fleet of servers handling the request after being routed are in a private network. With CF, the request from CF to the origin is over a public network and it will depend on how the user has configured their CF setup as to whether or not that hand-off is then encrypted. If they are doing SSL termination in CF, then it won't be encrypted from CF to the origin server.
slig 7y ago
Yes, it's called "flexible SSL".

namibj 7y ago

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.

Sukera 7y ago
Do you have a source on that? Quite a few people seem to disagree: https://istlsfastyet.com/ https://istlsfastyet.com/
- deleted 7y ago
  [deleted]
- namibj 7y ago
  Oh, yeah, for good clients it's totally fine. But e.g. a machine I'll try an http benchmark on in a couple hours (2 cires; 4780 BogoMIPS each) only managed 4177 ops/s using the fastest-available curve X25519 with openssl speed ecdh gatling -V -n -p 80 -u nobody I know this is somewhat extreme, but on a cpu that was about 30% faster I got 40k rps for small files using the kernel's loopback, which is where the cpu spent most of it's time. Feel free to try.
  - dependenttypes 7y ago
    This should happen only during the handshake though.
- kevingadd 7y ago
  In my testing for high-throughput scenarios like copies over ssh/rsync/https/smb (i tried them all) in every case encryption was a big hit to throughput. hardware assistance (built into the CPU) helped a lot but it was still a massive boost to shut off encryption - saving literal minutes on every bulk transfer, multiple transfers per day. For the average case it probably doesn't matter, and you can optimize it, but I think it is totally understandable that the average novice could end up with bad https performance if only because the defaults are bad or they made a mistake. If hardware assist for the handshake and/or transfer crypto is shut off (or unavailable, on lower-spec CPUs) your perf is going to tank real hard. I ended up using ssh configured to use the weakest (fastest) crypto possible, because disabling crypto entirely was no longer an option. I controlled the entire network end to end so no real risk there - but obviously a dangerous tool to provide for insecure links. Also worth keeping in mind that there are production scenarios now where people are pushing 1gb+ of data to all their servers on every deploy - iirc among others when Facebook compiles their entire site the executable is something like a gigabyte that needs to be pushed to thousands of frontends. If you're doing that over encrypted ssh you're wasting cycles which means wasting power and you're wasting that power on thousands of machines at once. Same would apply if the nodes pull the new executable down over HTTPS.

Thorrez 7y ago

The article says googletagmanager.com has HSTS preloading. But it doesn't. This is easily testable. I view the website in both Chrome and Firefox, and it's http, not https. Sure googletagmanager.com is in the preload list, but it doesn't have "mode": "force-https". It just has certificate pinning, not HSTS.

founderling 7y ago

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 letsencrypt should allow wildcards to the owner of somedomain.com without dabbling with the DNS. The way things are now, I don't use ssl for my smaller projects at smallproject123.mydomain.com because I don't want the hassle of yet another cronjob and I sometimes don't want the subdomain to go into a public registry (where all certificates go these days).

benjojo12 7y ago
There is a 2nd ACME free CA these days based in Norway: https://www.buypass.com/ssl/products/acme https://www.buypass.com/ssl/products/acme I used it on a pervious post to test it out and it seemed to be fine: https://github.com/benjojo/you-cant-curl-under-pressure/commit/eb163fc4dfef34760ff68be13e8ce88d78f6c017 https://github.com/benjojo/you-cant-curl-under-pressure/comm...
- founderling 7y ago
  Did you miss the "free" in my comment or am I missing something?
  - benjojo12 7y ago
    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 https://crt.sh/?id=2075589060
    - tyingq 7y ago

dijit 7y ago

I 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? It feels like a cargo cult. A requirement: “because!” In other scenarios it’s worth modelling threats and I agree that it’s good to err on the side of caution but aside from the modification of my connection information there’s no good tangible reason to incur an overhead in administration. Although it should be noted; part of the reason that web server even exists is to do letsencrypt for a globally geobalanced irc network.

founderling 7y ago
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. Exposing them to the pain of ecommerce fraud. If the page is altered to use a 0-day exploit, the pain is to have a zombie machine afterwards. Etc etc ...
- dijit 7y ago
  If you can inject such content (as in an arp poisoning or other man in the middle scenario) why wouldn’t you go after the dns requests?
  - Liquid_Fire 7y ago
    HTTPS will protect you against hijacked DNS requests as well.
    - dijit 7y ago
      Not by itself, if you have special HTTP headers it will. But some of those are deprecated (HPKP; for example)[0] [0]: https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning#Browser_support_and_deprecation https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning#Browse...

dvfjsdhgfv 7y ago

HTTPS is not an obligation. Most people believe it's a must these days, but it's not. There is a nice rebuttal of Troy's arguments on N-gate (via webcache as direct links from HN end up in an endless pseudo-captcha): http://webcache.googleusercontent.com/search?q=cache:t_oVSNuTvIgJ:n-gate.com/software/+&cd=1&hl=en&ct=clnk&gl=pl http://webcache.googleusercontent.com/search?q=cache:t_oVSNu...

edf13 7y ago

The 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 https://www.amazon.somethiing.other.co/greatDiscount may look great to some!

minitech 7y ago
This is exactly the opposite of a forcing HTTPS problem. When HTTPS isn’t everywhere, HTTPS gives a false sense of security. When it is, browsers can stop emphasizing it. We’re already well down that path, with padlocks no longer being green/being hidden entirely, EV certificates losing their confusion vector, insecure pages being assigned the icon that sticks out…
LeonM 7y ago
I think that was the main reason why browser vendors moved away from the green padlock symbol.
seqastian 7y ago
> The biggest problem with forcing everything HTTPS No it isn't. Https not being 100% bulletproof is unrelated to using it everywhere. And it's lightyears away from its biggest problem.
em-bee 7y ago
true but the only way to get there is to force http into oblivion. right now people think: 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...
simias 7y ago
If we migrate to HTTPS everywhere we can get rid of HTTP for general use and switch to a different UI, where HTTPS websites don't have any special icon but HTTP ones get a warning icon. It's already effectively how password form submissions work in many browsers.

altmind 7y ago

Preloads list is an absolute kludge that does not and will never scale and creates a huge deal of problems and works only for specific browsers. The task is not as simple as using DNS to store strict https flags(as DNS can be manipulated by intermediary), but hardcoding the lists in the browsers and keeping the lists in the chrome's code is definitely not a solution.

kuschku 7y ago
The goal is to slowly move higher levels into that list. e.g. in the past it was just domains and subdomains. Today there are already some TLDs on the list themselves.
Avamander 7y ago
The solution is to make the default connection port 443 HTTPS and allow people to drop listening on port 80.

SlowRobotAhead 7y ago

Am I missing something? Lots of US sites on their NO HTTPS list come up in Safari as HTTPS. Rutgers.edu for example.

davidmurdoch 7y ago

One potentially good reason to not force SSL: https://meyerweb.com/eric/thoughts/2018/08/07/securing-sites-made-them-less-accessible/ https://meyerweb.com/eric/thoughts/2018/08/07/securing-sites... TL;DR: Secure websites can make the web less accessible for those who rely on metered satellite internet (and I'm sure plenty of other cases).

satanspastaroll 7y ago
Trading security for convenience is rarely a good idea. The rest of the world should not conform the to failures of certain areas to provide internet.
- oneeyedpigeon 7y ago
  No, but it's a good idea to have the option, so long as people are aware of the implications.
- rkagerer 7y ago
  Unfortunately convenience usually does tradeoff against security. Thoughtful UX can deliver both, but it's rare to find in practice. That casual dismissal of davidmurdoch's counterargument comes across tone-deaf to people stuck on crappy connections.
- davidmurdoch 7y ago
  I see your point. But we trade security for convenience 24/7/365. We could all have bulletproof glass in our homes, personal security cameras everywhere, backup generators, panic rooms, etc, but we don't, because it's not convenient (and I know the expense is primarily what makes it not convenient, but I think it's still a valid argument). Providing access to Wikipedia over http to people in third world countries may be worth the risk of someone MITMing the site with propaganda. The suggestion is only to give some users the option.
  - pixl97 7y ago
    Mitm with propaganda is the least of the worries. Full on exploit code is. The fact is as an ecosystem develops completely increases. Lifeforms in that ecosystem have to spend more time and effort protecting themselves from outside attacks as time progresses.

BrandoElFollito 7y ago

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.

zurn 7y ago
Let's Encrypt works on internal networks too. Fun fact: TLS doesn't require certificates, and some browsers even used to support HTTPS in these TLS modes many moons ago. See eg https://security.stackexchange.com/questions/23024/can-diffie-hellman-anonymous-be-used-as-a-cipher-for-ssl-for-one-way-certifiate#23025 https://security.stackexchange.com/questions/23024/can-diffi...
- BrandoElFollito 7y ago
  Ah? That's good to know! How to set this up on a domain which is not connected to Internet? How is the check done?
  - benoliver999 7y ago
    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).
    - BrandoElFollito 7y ago
      The problem is that I also have domains which are completely internal, not known/resolvable outside
      - cheschire 7y ago
        Could you run an internal CA server instead of self signing? At least then you reduce your attack surface if you’re compromised internally.

faissaloo 7y ago

Because even Certbot is a massive pain to setup if you're not using a very generic setup

dm33tri 7y ago

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.

couchand 7y ago
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.
- dm33tri 7y ago
  You can't assume protection, whereas with http you assume no protection. So, if you can't trust certificate (not when it is invalid), just show same level of protection as http.
  - zozbot234 7y ago
    The problem is that a http: protocol specifier implies no protection; the moment you follow the link, you know that the connection is not secured. Whereas a self-signed https: connection could be due to someone MITM'ing a site that generally uses CA's, in which case "no warning message" implies that the site is secured. The browser message has to make it clear to the user that something possibly unexpected is going on.
- deleted 7y ago
  [deleted]
- JackRabbitSlim 7y ago
  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.
  - arminiusreturns 7y ago

strenholme 7y ago

One annoyance with this system, from the linked webpage: >an expectation that a site responds to an HTTP request over the insecure scheme with either a 301 or 302 Doing things this way is the final nail in the coffin for Internet Explorer 6, since IE6 does not use any version of SSL which is considered secure here in 2019. And, yes, I have seen in people the real world still using ancient Internet Explorer 6 as recently as 2015, and Windows XP as recently as 2017. Which is why I instead do the http → https redirection with Javascript: I make sure the client isn’t using an ancient version of Internet Explorer, then use Javascript to move them to the https version of my website. This way, anyone using a modern secure browser gets redirected to the https site, while people using ancient IE can still use my site over http. (No, I do not make any real attempt to have my HTML or CSS be compatible with IE6, except with https://samiam.org/resume/ https://samiam.org/resume/ and I am glad the nonsense about “pixel perfect” and Flash websites is a thing of the past with mobile everywhere)

namibj 7y ago
Be aware that blocking scripts from insecure connections is something you'd usually want to do...
- strenholme 7y ago
  “usually” being the operative word. I’m not quite ready to throw IE6 (Internet Explorer 6) and all http-only browsers completely under a bus yet.
Wingy 7y ago
Why not look at the User-Agent header and 301 to https if you don't see IE6?
- strenholme 7y ago
  That’s actually a good idea. It was simpler to set up the Javascript redirect. It I were to go that way, I would probably redirect IE6 to a “neverssl” subdomain (which also would be useful for dealing with WiFi capture portals).

andrewfromx 7y ago

i still use https://neverssl.com https://neverssl.com daily. I hope it never goes away.

IggleSniggle 7y ago
Wow that's pretty interesting! Thanks for sharing.
nhumrich 7y ago
Intentional that your link is https?
- andrewfromx 7y ago
  ha, no i think HN did that automatically? I wrote http without s

fiatjaf 7y ago

Because it's hard and a pain. Sure, depending on your setup it's easy, but for a lot of setups it isn't. Instead of trying to say HTTPS is easy and shame everybody who isn't doing it more efforts should be diverted into creating an actual fully encrypted network that doesn't need CAs.

fiatjaf 7y ago
What actually happens when you try to force HTTPS over the internet: you centralize it, you make it harder for the small player, hobbyist, personal homepage guy, and make it easier for the big corporation.

forgottenpass 7y ago

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.

netsectoday 7y ago

Without HSTS preload anyone on your local network can arp/dns spoof your traffic, MITM you, and automatically inject malicious javascript (cryptominers, credential-stealers, etc.), access all of the page content, and manipulate the page or response. If you are connecting to a "Free Public WiFi" and the malicious actor is the one broadcasting the access-point; it's even easier to MITM you. Without Cert & Key Pinning your employee laptop can be MITM by corporate to eavesdrop on all of your HTTPS traffic. The browser will show that the connection is secure, but it isn't. When you pin the cert and key - even with a compromised corporate computer - the insecure site warning will show and you'll be alerted to the fuckery. > Doing things this way is the final nail in the coffin for Internet Explorer 6 - Fucking great! Nothing else to say here. > handshakes take enormous amounts of CPU - This is vastly overstated (enormous?). Also, this is called a tradeoff. Security isn't free in time, money, or performance. > Preloads list is an absolute kludge that does not and will never scale... and works only for specific browser - The preload list, right now, is 10.6mb and contains 90,862 entries. This seems to function and scale just fine. Seeding your browser with known values is really the best way to do this until 99.X% of web traffic is provided over HTTPS... Also Chrome, Firefox, Safari, IE/Edge, and Opera make up 98% of all browser traffic today and they have all supported this standard for years. > The biggest problem with forcing everything HTTPS is a false sense of security. - Defense in depth. Layering security controls is the only way to go. Also; this is some crazy mental gymnastics to take the position "wearing a seatbelt is a false sense of security because you can still crash". > Because it's hard and a pain. - Feeling that pain is offset onto the attackers trying to compromise your site. If you don't feel the pain; they don't either. > Secure websites can make the web less accessible for those who rely on metered satellite internet... TLS 1.3 with 1-RTT should improve this situation. - Even if your entire business depended upon delivering data to metered satellite internet users; the risk outweighs the cost when not encrypting your traffic. WARNING: DON'T IMPLEMENT 0-RTT OR 1-RTT WITHOUT UNDERSTANDING YOUR APPLICATION-SPECIFIC REQUIREMENTS. You can really fuck this up by not properly managing tokens between your webserver and application layer. Not recommended. > I don't get it. With Lets Encrypt, it's like one or two lines to get everything set up. - True, but it get's confusing really fast if you don't 100% match the certbot use-case. > HTTPS is not an obligation. - For 99% of people running businesses; it is. > Recently an OpenShift cluster I admin went down because of long-lived certs not being rotated in time. - If you have had certbot running for a long time I would suggest you check your server logs TODAY and make sure your cron job is still working correctly. Recently there was a change with the certbot acme version requirement and your reissue might be failing. Seriously, take a quick look right now. > Because frankly, I neither trust letsencrypt nor the certificate authority system in general... but won't help against industrial (e)spionage - Places tinfoil hat on... you're not wrong.

z3t4 7y ago

Had to access an EOL device and couldn't browse the web because of all ended certificates...

jzl 7y ago

I clicked through to the list of sites. Embarrassing to see that mit.edu is not https by default! The same institution invented Kerberos. Come on MIT, fix this please.

bo1024 7y ago

Maybe I’m wrong, but I feel SSL has a downside of relying on more centralization. If a visitor to my totally-static webpage wants to bypass that layer and request the http version directly, I’m going to let them. (Obviously not excited about the idea of being mitm’d but it’s not a security risk, so leave that tradeoff up to the visitor).

pornel 7y ago
https://doesmysiteneedhttps.com/ https://doesmysiteneedhttps.com/ MITM can do anything to your site, so your totally-static site may not be static any more at the victim's end. It may be a site collecting private details, attacking the browser, or using the victim to attack other sites. Your static HTTP site is a network vulnerability and a blank slate for the attacker.
- anony121212 7y ago
  So then disable javascript for http sites
  - Sohcahtoa82 7y ago
    That won't do anything. If someone can Man-in-the-Middle you, then they can easily forge a 302 redirection to a malicious web page that could be HTTPS.
  - pixl97 7y ago
    Ok, cool, I found a new numerical overflow image rendering in your browser library. Now I can shove an <img> tag in the insecure stream and exploit you.
- bo1024 7y ago
  Thanks for the reply. I've seen that site but it seems to be aimed at people who don't offer any https at all. At this point I'm still more comfortable offering visitors the decision. (Not many people visit my site by the way.)

bullen 7y ago

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

DuskStar 7y ago
Do you have a description of how you made your own security and what it provides?
- bullen 7y ago
  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".
  - necovek 7y ago
    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 you using self-signed certs, and likely even worse because there are more attack vectors even outside the initial connection.
    - bullen 7y ago
      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!!!

anony121212 7y ago

Ability to write my own HTTP server from scratch. Content is for downloading and use offline.

LinuxBender 7y ago

It isn't just web sites. Many software repos still use http or native rsync. Some would argue that you validate the packages with GPG, but you would be amazed if you saw how many people install the GPG public key from the same mirror they download software from.

surge 7y ago
Gradle, granted they're fixing it. https://blog.gradle.org/decommissioning-http https://blog.gradle.org/decommissioning-http

vivekd 7y ago

One thing that surprised me was how hard it was to set up https https redirects for websites on aws and Google cloud. I needed too set up a load balancer to do https. The redirects are also hard, I have a static site using Google storage and I have to create a server instance and redirect from there because it's not possible to do an automatic redirect. I don't know why the big cloud hosting providers aren't cooperating to make full https implementation easier.

gmiller123456 7y ago

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.

pixl97 7y ago
Um, the number of people connected to my ssh server I can count on my fingers, and generally have communicated with beforehand. The number of people communicating with my https server is one larger than I could ever count to monitonically. If you dont get the difference in scale between the two you might have an issue understanding the real problem.
xvector 7y ago
> 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. Genuinely curious - what alternatives do you have in mind? Are there any WoT models that interest you more? > There is currently only one free cert provider, if there are ever issues with it, your users will see a scary error message Isn't this the point? > Downloading and running code from a 4th, or 5th party and giving it access to your config files is not "more secure". Could you elaborate? Have you written your whole stack from scratch? You are running millions of lines of code that you will never read but have been implemented by other parties. > HTTPS is needlessly complex making it hard to implement. Isn't this done with robust battle-tested libraries and built-in support in modern languages? --- Mainly I'm just wondering why you're letting perfect be the enemy of good. There's always room for improvement in everything, but I don't think user privacy is a reasonable sacrifice to make. > Giving in ends the hope that it will ever get changed. Abstaining from HTTPS won't be seen by anyone as a protest, but as incompetency, whether you find that justifiable or not.

mohas 7y ago

Many of us have to host our websites on shared hosts that does not support HTTPS freely, HTTPS costs money in the third world

necovek 7y ago

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 unavailable. Sure, some sites have broken https endpoints, but browsers have enforced crazier shit recently.

discreditable 7y ago
Annoyingly, if you want to get a let's encrypt cert you have to serve http. Back when I was manually purchasing & installing certs I didn't even listen on 80 for several services. (Exception being if you use the dns challenge)
- vunie 7y ago
  >(Exception being if you use the dns challenge) Exactly. DNS challenges don't suffer from this issue.
kuschku 7y ago
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 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.
- necovek 7y ago
  Right, so HSTS will protect a visitor who has visited your web site at most max-age ago using that particular browser and device. Or, as I stated, for preload, you have to either not have HTTP at all, or have a redirect to HTTPS: it should be clear from my above post why I think a redirect is a bad idea. I also dislike turning off HTTP for those that don't have any other option. To me it seems that browsers just switching to https-by-default and http-as-fallback is a much simpler, better, backwards-compatible change that should just work. What am I missing and why do you feel HSTS is a good idea compared to that?

printercenter 7y ago

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-message/ https://printerhelpcenter.com/replace-brother-drum-error-mes... https://printerhelpcenter.com/how-to-fix-canon-printer-error-b200/ https://printerhelpcenter.com/how-to-fix-canon-printer-error...

romwell 7y ago

I consider myself young, but I've been around long enough to to rely on One True Service Provider for anything. And "Let's Encrypt" is not an answer to "HTTPS is not free". It's not. We all are going to see our projects outlive Let's Encrypt (or their free tier). In the end, nothing is secure. A dedicated attacker will find a way, given enough resources. Any security measure is just a deterrent. My deterrent is that it's not worth MITM'ing my personal website with, like, 10 monthly visitors. (The reader might gasp that I lock my bicycle with a chain that can be snapped in a second, and that a strong enough human can probably bash my home door in). Anyway. It's almost 2020, and if you are still advocating on moving the entirety of the Web to reliance on Big Centrally Good Guys, I really don't know what else to say to you.