7 ms·

I've noticed that a lot of the hostility towards HTTPS comes from those who do really shady things online. Like pop-under advertisers that are unhappy that they

I've noticed that a lot of the hostility towards HTTPS comes from those who do really shady things online. Like pop-under advertisers that are unhappy that they have to update their own infrastructure, otherwise their unsafe mixed content won't be loaded by a browser. So no, not HTTPS is a threat, but company's unwillingness to innovate. So Chrome's and Firefox's public shaming of unsafe websites is really doing everyone a service. The best thing I've ever done to serving HTTPS was to use Caddy with Let's Encrypt. Seriously. It was incredibly easy to set up. And I've never used Caddy before. https://caddyserver.com/docs/automatic-https https://caddyserver.com/docs/automatic-https describes how to have TLS available right from the first request served.

jrimbault 9y ago
I hope the packages for Apache in mainstream distros will include good defaults settings, I remember somehow hunting for the rules to redirect to https.
Spivak 9y ago
The other hostility being that HTTPS bundles encryption with identity verification. The fact that we've bundled the practical ability to encrypt your site with a 3rd party gatekeepers is really off-putting to people. A self-signed cert could be supported and effectively trust on first use like SSH and have the same trust model as a DV cert.
- snowwrestler 9y ago
  I don't know how you use SSH, but I don't permit or establish anonymous SSH connections the way I do anonymous HTTPS connections. SSH is "trust on first use" because the trust is typically established ahead of time by provisioning a username/password or a public/private key pair. Along the same lines, I can use self-signed certs to encrypt the HTTPS connection to my own server, and feel confident because I can validate that it is really my cert and my server. The same is not true of connecting to, say, twitter.com.
  - iancarroll 9y ago
    You are right in that SSH is TOFU because trust can be established beforehand, but you cannot establish trust based on whether or not a password or public key is accepted. You need to establish trust separately (with the server's public key), usually before you ever authenticate. For passwords, it's obvious, because a malicious server can just save your username and password, but public keys are not immune either, as a bad actor can "pretend" to be your server and hope you enter an access key or something.
    - icebraining 9y ago
      Actually, you can, and just using passwords! Using a PAKE protocol, the client and the server can prove to each other that they know a certain password, without revealing it. And you can even tie that to TLS: https://en.wikipedia.org/wiki/TLS-SRP https://en.wikipedia.org/wiki/TLS-SRP
      - iancarroll 9y ago
        Yes, but SRP for SSH isn't specified or implemented into any SSH implementation that I know of. My comment was about SSH today, as apparently the GP is currently using this as a method to authenticate servers.
        icebraining 9y ago
        Ah, fair enough. As a matter of curiosity, OpenSSH did start an implementation of J-PAKE, but it was abandoned before ever becoming stable :|
- mschuster91 9y ago
  > A self-signed cert could be supported and effectively trust on first use like SSH and have the same trust model as a DV cert. No, it can not. Self-signed certs, if not verified prior to first visit to a site or being trusted in case of company intranet sites, are vulnerable to a MITM attack - which is why browsers are warning if they can't detect a valid trust path. Also, SSH is only secure on first use if you verify the fingerprints (and that is why ssh will ask you if you know/trust the hash on first connect). Side question: does anyone know of a SSH "loadbalancer", working like HTTPS SNI so that multiple domains can have ssh on the same IP and port?
  - wolfgang42 9y ago
    > Side question: does anyone know of a SSH "loadbalancer", working like HTTPS SNI so that multiple domains can have ssh on the same IP and port? I think the term you're looking for is "bastion host" or "jump host". Basically you SSH into the bastion server and then run another SSH command to get to the destination server; newer versions of the SSH client apparently support a -J option to do this automatically.
    - beagle3 9y ago
      But that's not loadbalancing - you still have to trust any host you get to through the jump host; with a new enough ssh and sshd, you can use a CA to sign host or client keys, and get an experience similar to https. (There is even a DNS record for that, iirc) Any TCP loadbalancer will do as long as all the hosts share the host key, which is considered bad practice but isn't worse than e.g. Sharing a TLS certificate, which is not considered a horrible practice.
      - wolfgang42 9y ago
        They weren't looking for load balancing in the "keep it even between identical hosts" sense, but rather in the manner that you might use a "load balancer" appliance to look at the SNI and direct the request to the correct machine for the given hostname. (See our conversation elsewhere on the thread for why they wanted to do this.)
- snakeanus 9y ago
  I wish that modern browsers made it possible to trust a CA certificate only for specific sites, or to pin the one used in a specific site so other CAs can't be used silently. I also wish that more browsers supported OpenPGP certificates instead, as it is a simpler while at the same time more powerful format (allows for multiple signatures for example).
  - thefifthsetpin 9y ago
    HSTS already protects you from attackers that get another CA to sign their certificate. There would be obvious problems with encouraging you as a user manage pinning (how would you know whether a site will deviate from what you pinned?) If you understand that but want to pin as a user anyway, chrome will let you do that: chrome://net-internals/#hsts
    - snakeanus 9y ago
      >chrome will let you do that: chrome://net-internals/#hsts Aren't the hashes there only for the public keys of the site instead of the public key of the CA? Also, does anybody happens to know any extension for Firefox that does anything similar to that?
    - wolfgang42 9y ago
      I think that's HPKP you're thinking of; HSTS only declares that the site plans to continue requiring HTTPS without specifying a CA or public key that it will use.
- veeti 9y ago
  > A self-signed cert could be supported and effectively trust on first use like SSH Hopefully needless to say, it's a bad idea to blindly connect to SSH hosts without verifying the fingerprint. (Of course, everyone just types in "yes" because they're lazy). You have absolutely no guarantee you're talking to your server. Hostile wi-fi networks, firewalls, ISP's and regimes mess with plain HTTP all the time. A TOFU "trust model" would make that a commonplace reality for HTTPS as well. For what it's worth, verifying SSH hosts should be much easier than it is. For example, every cloud provider should display the host fingerprint after creating a new instance.
headmelted 9y ago
You and this Troy Hunt guy have completely missed the central point that Maria is making. "Some are on domain validation which is 2048+ BitSH42 SSL/TLS encryption the encryption key is limited which means you can use on a few pages and has a limited band weight" What about THESE people? The ones on limited band weights that can only use a few pages? This is a 100% valid complaint about 2048+ BitSH42 protocols that I've had for some time and no-one ever acknowledges it or suggests a solution.
- justusw 9y ago
  Are you referring to The Band - The Weight? If so, then it is a fine song.
  - headmelted 9y ago
    Were this reddit I'd invite you to take a load off, but that kind of behaviour invites (incites?) downvotes round here. So I shan't!
    - LambdaComplex 9y ago
      But apparently saying you'd get downvoted gets you downvoted just the same. Just like on Reddit!
      - headmelted 9y ago
        You know what? It's fair. I'd downvote me for saying "hope I don't get downvoted" too. On a side note, I'm glad at least one other person listens to The Band. Rock and roll is not dead! (Or it is, if Lester Bangs in Almost Famous is to be believed). I've gone well off the thread and into the wilderness here haven't I?
  - FilthyAnalyst 9y ago
    It would make more sense that way.
- wolf550e 9y ago

jrimbault 9y ago

I hope the packages for Apache in mainstream distros will include good defaults settings, I remember somehow hunting for the rules to redirect to https.

Spivak 9y ago

The other hostility being that HTTPS bundles encryption with identity verification. The fact that we've bundled the practical ability to encrypt your site with a 3rd party gatekeepers is really off-putting to people. A self-signed cert could be supported and effectively trust on first use like SSH and have the same trust model as a DV cert.

snowwrestler 9y ago
I don't know how you use SSH, but I don't permit or establish anonymous SSH connections the way I do anonymous HTTPS connections. SSH is "trust on first use" because the trust is typically established ahead of time by provisioning a username/password or a public/private key pair. Along the same lines, I can use self-signed certs to encrypt the HTTPS connection to my own server, and feel confident because I can validate that it is really my cert and my server. The same is not true of connecting to, say, twitter.com.
- iancarroll 9y ago
  You are right in that SSH is TOFU because trust can be established beforehand, but you cannot establish trust based on whether or not a password or public key is accepted. You need to establish trust separately (with the server's public key), usually before you ever authenticate. For passwords, it's obvious, because a malicious server can just save your username and password, but public keys are not immune either, as a bad actor can "pretend" to be your server and hope you enter an access key or something.
  - icebraining 9y ago
    Actually, you can, and just using passwords! Using a PAKE protocol, the client and the server can prove to each other that they know a certain password, without revealing it. And you can even tie that to TLS: https://en.wikipedia.org/wiki/TLS-SRP https://en.wikipedia.org/wiki/TLS-SRP
    - iancarroll 9y ago
      Yes, but SRP for SSH isn't specified or implemented into any SSH implementation that I know of. My comment was about SSH today, as apparently the GP is currently using this as a method to authenticate servers.
      - icebraining 9y ago
        Ah, fair enough. As a matter of curiosity, OpenSSH did start an implementation of J-PAKE, but it was abandoned before ever becoming stable :|
mschuster91 9y ago
> A self-signed cert could be supported and effectively trust on first use like SSH and have the same trust model as a DV cert. No, it can not. Self-signed certs, if not verified prior to first visit to a site or being trusted in case of company intranet sites, are vulnerable to a MITM attack - which is why browsers are warning if they can't detect a valid trust path. Also, SSH is only secure on first use if you verify the fingerprints (and that is why ssh will ask you if you know/trust the hash on first connect). Side question: does anyone know of a SSH "loadbalancer", working like HTTPS SNI so that multiple domains can have ssh on the same IP and port?
- wolfgang42 9y ago
  > Side question: does anyone know of a SSH "loadbalancer", working like HTTPS SNI so that multiple domains can have ssh on the same IP and port? I think the term you're looking for is "bastion host" or "jump host". Basically you SSH into the bastion server and then run another SSH command to get to the destination server; newer versions of the SSH client apparently support a -J option to do this automatically.
  - beagle3 9y ago
    But that's not loadbalancing - you still have to trust any host you get to through the jump host; with a new enough ssh and sshd, you can use a CA to sign host or client keys, and get an experience similar to https. (There is even a DNS record for that, iirc) Any TCP loadbalancer will do as long as all the hosts share the host key, which is considered bad practice but isn't worse than e.g. Sharing a TLS certificate, which is not considered a horrible practice.
    - wolfgang42 9y ago
      They weren't looking for load balancing in the "keep it even between identical hosts" sense, but rather in the manner that you might use a "load balancer" appliance to look at the SNI and direct the request to the correct machine for the given hostname. (See our conversation elsewhere on the thread for why they wanted to do this.)
snakeanus 9y ago
I wish that modern browsers made it possible to trust a CA certificate only for specific sites, or to pin the one used in a specific site so other CAs can't be used silently. I also wish that more browsers supported OpenPGP certificates instead, as it is a simpler while at the same time more powerful format (allows for multiple signatures for example).
- thefifthsetpin 9y ago
  HSTS already protects you from attackers that get another CA to sign their certificate. There would be obvious problems with encouraging you as a user manage pinning (how would you know whether a site will deviate from what you pinned?) If you understand that but want to pin as a user anyway, chrome will let you do that: chrome://net-internals/#hsts
  - snakeanus 9y ago
    >chrome will let you do that: chrome://net-internals/#hsts Aren't the hashes there only for the public keys of the site instead of the public key of the CA? Also, does anybody happens to know any extension for Firefox that does anything similar to that?
  - wolfgang42 9y ago
    I think that's HPKP you're thinking of; HSTS only declares that the site plans to continue requiring HTTPS without specifying a CA or public key that it will use.
veeti 9y ago
> A self-signed cert could be supported and effectively trust on first use like SSH Hopefully needless to say, it's a bad idea to blindly connect to SSH hosts without verifying the fingerprint. (Of course, everyone just types in "yes" because they're lazy). You have absolutely no guarantee you're talking to your server. Hostile wi-fi networks, firewalls, ISP's and regimes mess with plain HTTP all the time. A TOFU "trust model" would make that a commonplace reality for HTTPS as well. For what it's worth, verifying SSH hosts should be much easier than it is. For example, every cloud provider should display the host fingerprint after creating a new instance.

headmelted 9y ago

You and this Troy Hunt guy have completely missed the central point that Maria is making. "Some are on domain validation which is 2048+ BitSH42 SSL/TLS encryption the encryption key is limited which means you can use on a few pages and has a limited band weight" What about THESE people? The ones on limited band weights that can only use a few pages? This is a 100% valid complaint about 2048+ BitSH42 protocols that I've had for some time and no-one ever acknowledges it or suggests a solution.

justusw 9y ago
Are you referring to The Band - The Weight? If so, then it is a fine song.
- headmelted 9y ago
  Were this reddit I'd invite you to take a load off, but that kind of behaviour invites (incites?) downvotes round here. So I shan't!
  - LambdaComplex 9y ago
    But apparently saying you'd get downvoted gets you downvoted just the same. Just like on Reddit!
    - headmelted 9y ago
      You know what? It's fair. I'd downvote me for saying "hope I don't get downvoted" too. On a side note, I'm glad at least one other person listens to The Band. Rock and roll is not dead! (Or it is, if Lester Bangs in Almost Famous is to be believed). I've gone well off the thread and into the wilderness here haven't I?
- FilthyAnalyst 9y ago
  It would make more sense that way.
wolf550e 9y ago