4 ms·

As far as I know, Firefox still allows this for any expired certificate which at least has correct domain details and authority (e.g. it once worked, which some

As far as I know, Firefox still allows this for any expired certificate which at least has correct domain details and authority (e.g. it once worked, which some dev should validate). SSL version or cipher mismatch can be from other causes. For example, the server might be responding with a html page that your browser is interpreting as https or vice versa, such as if the developers run http for local dev and https for prod and something gets confused.

deathanatos 3y ago
> SSL version or cipher mismatch can be from other causes. For example, the server might be responding with a html page that your browser is interpreting as https or vice versa, No, it's speaking TLS; it (the server) sends a TLS fatal alert & disconnects immediately after the ClientHello. It's odd, too; I asked nmap to show what ciphersuites the server offers, and it seems like what nmap was able to elicit indicates there is overlap between what's offered by the client and the server. So … IDK what is going on here. (It seems like the server isn't doing cipher suite negotiation correctly, AFAICT. The server-offered cipher suite set is a bit … unusual looking? E.g., no DHE, but ECDHE, but also non-DHE?)
- Izkata 3y ago
  > and it seems like what nmap was able to elicit indicates there is overlap between what's offered by the client and the server. On your client, maybe the person getting this is just out of date? (Or are you getting the same thing?)
  - deathanatos 3y ago
    I'm getting the same error from Firefox, no cipher suite overlap. But I can see in Wireshark FF's ClientHello, and some of the cipher suites in that ClientHello seem to appear in the output that nmap says is the server's available cipher suites. So, I am perplexed. (And I'm on Arch; my FF can't be too far behind.)

4 ms·

As far as I know, Firefox still allows this for any expired certificate which at least has correct domain details and authority (e.g. it once worked, which some

by james-revisoai 3y ago

deathanatos 3y ago
> SSL version or cipher mismatch can be from other causes. For example, the server might be responding with a html page that your browser is interpreting as https or vice versa, No, it's speaking TLS; it (the server) sends a TLS fatal alert & disconnects immediately after the ClientHello. It's odd, too; I asked nmap to show what ciphersuites the server offers, and it seems like what nmap was able to elicit indicates there is overlap between what's offered by the client and the server. So … IDK what is going on here. (It seems like the server isn't doing cipher suite negotiation correctly, AFAICT. The server-offered cipher suite set is a bit … unusual looking? E.g., no DHE, but ECDHE, but also non-DHE?)
- Izkata 3y ago
  > and it seems like what nmap was able to elicit indicates there is overlap between what's offered by the client and the server. On your client, maybe the person getting this is just out of date? (Or are you getting the same thing?)
  - deathanatos 3y ago
    I'm getting the same error from Firefox, no cipher suite overlap. But I can see in Wireshark FF's ClientHello, and some of the cipher suites in that ClientHello seem to appear in the output that nmap says is the server's available cipher suites. So, I am perplexed. (And I'm on Arch; my FF can't be too far behind.)