4 ms·

My favorite HTTPS bug: Websites prove their identity via certificates. Firefox does not trust this site because it uses a certificate that is not valid for www

My favorite HTTPS bug: Websites prove their identity via certificates. Firefox does not trust this site because it uses a certificate that is not valid for www.daniellesucher.com. Error code: MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT View Certificate --- Followed by: "Site not found"

q3k 7y ago
Just because it serves HTTPS on port :443 doesn't mean you should be using it. 'HTTPS Everywhere' style plugins are a broken concept.
- ivanbakel 7y ago
  In what way are they a broken concept? What justification is there for serving HTTPS in a way users can't expect to consume?
  - tych0 7y ago
    If you don't serve the same content on :80 and :443. For example, you might be running a Tor relay node which would serve the node directory list on :443 to help people bypass firewalls, but also be using it as a useful and legitimate web server in order to prevent organizations from blocking it wholesale.
  - Lex-2008 7y ago
    Somebody might prefer using http for public stuff (reading blog posts), https for private (editing them).
  - q3k 7y ago
    > In what way are they a broken concept? Because it's blindly following an inadequate heuristic, and not gracefully degrading if it fails - instead, you get comments like these blaming the author. Even though the author never wanted you to use HTTPS in the first place. > What justification is there for serving HTTPS in a way users can't expect to consume? Plenty of technical reasons (eg. what the sibling comments mentioned), but most importantly: there's no Internet/Web standard that I'm aware of which would prohibit me from doing so.
- 0xff00ffee 7y ago
  cool. i like fried cheese, too.
  - q3k 7y ago
    But the author was following convention: serving HTTP on traffic :80, and linking to that explicitly. It's you, the user, who for some reason decided to switch to a different protocol on a different port, and expected it to work even though there was no guarantee or indication that it would.
    - asudosandwich 7y ago
      Could be a new hobby for the author. Like https://xkcd.com/148/ https://xkcd.com/148/
- zoonosis 7y ago
  HTTPS Everywhere works based on rules as to which sites support https. It does not blindly redirect every request to port 443.
Spivak 7y ago
There isn't a HTTPS version of the site so you get dropped into the default vhost for their hosting provider, DreamHost. DreamHost could automatically issue LE certs for their customers but that's not how they do things and don't enable it without customer approval. It is impossible for DreamHost to not give you an error in this case. You connected directly to port 443 with a name that they don't have a certificate for. They could just close the connection but I don't think that would be an improvement on the situation.
0xff00ffee 7y ago
EDIT: Ok then, looks like default port conventions don't really mean anything. Sorry I brought it up.

q3k 7y ago

Just because it serves HTTPS on port :443 doesn't mean you should be using it. 'HTTPS Everywhere' style plugins are a broken concept.

ivanbakel 7y ago
In what way are they a broken concept? What justification is there for serving HTTPS in a way users can't expect to consume?
- tych0 7y ago
  If you don't serve the same content on :80 and :443. For example, you might be running a Tor relay node which would serve the node directory list on :443 to help people bypass firewalls, but also be using it as a useful and legitimate web server in order to prevent organizations from blocking it wholesale.
- Lex-2008 7y ago
  Somebody might prefer using http for public stuff (reading blog posts), https for private (editing them).
- q3k 7y ago
  > In what way are they a broken concept? Because it's blindly following an inadequate heuristic, and not gracefully degrading if it fails - instead, you get comments like these blaming the author. Even though the author never wanted you to use HTTPS in the first place. > What justification is there for serving HTTPS in a way users can't expect to consume? Plenty of technical reasons (eg. what the sibling comments mentioned), but most importantly: there's no Internet/Web standard that I'm aware of which would prohibit me from doing so.
0xff00ffee 7y ago
cool. i like fried cheese, too.
- q3k 7y ago
  But the author was following convention: serving HTTP on traffic :80, and linking to that explicitly. It's you, the user, who for some reason decided to switch to a different protocol on a different port, and expected it to work even though there was no guarantee or indication that it would.
  - asudosandwich 7y ago
    Could be a new hobby for the author. Like https://xkcd.com/148/ https://xkcd.com/148/
zoonosis 7y ago
HTTPS Everywhere works based on rules as to which sites support https. It does not blindly redirect every request to port 443.

Spivak 7y ago

There isn't a HTTPS version of the site so you get dropped into the default vhost for their hosting provider, DreamHost. DreamHost could automatically issue LE certs for their customers but that's not how they do things and don't enable it without customer approval. It is impossible for DreamHost to not give you an error in this case. You connected directly to port 443 with a name that they don't have a certificate for. They could just close the connection but I don't think that would be an improvement on the situation.

0xff00ffee 7y ago

EDIT: Ok then, looks like default port conventions don't really mean anything. Sorry I brought it up.