You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
feature request: server that does not support the Renegotiation Indication Extension (RFC 5746) #507
If this is relatively straightforward to configure in nginx, then I'd be happy to take a PR adding a new subdomain for this (or a snippet of nginx configuration I could use to set one up when I have a chance). New purely server-config tests are pretty easy to support (versus ones that require new and funky certificates).
I tried to look at it via nginx, it does not seem trivial. I had much difficulty implementing it myself since it seems TLS libs like OpenSSL don't expose it, and had to fall back to just mocking a packet via Raw TCP.
Ah yeah if it requires the server misbehaving in a way that OpenSSL doesn't directly support, then it's likely that we can't do it on badssl.com as the overhead of running custom server daemons is too much. We rely on static nginx configurations (and some weird edge case certificates) to do all the work for us.
I'm hosting a "community server" for this if anyone wants to test: https://rfc5746.mywaifu.best:4433 (note the port). It's running on Oracle free tier, will try to keep it up.
I'm hosting a "community server" for this if anyone wants to test: https://rfc5746.mywaifu.best:4433 (note the port). It's running on Oracle free tier, will try to keep it up.
I just tried it, seems to work. What is the exact command you're trying? The tool I wrote to replicate is very hacky, so it may not work unless you're explicitly using HTTPS.
Which OS are you using? One guess I have is the cURL command is not using OpenSSL but something else (an earlier log you posted mentioned SChannel, which is Windows). I have only tested it via cURL + OpenSSL.
On a browser I don't expect it to work, since I think the TLS handshake fails at such an early stage that a browser won't show any error in particular.
However, you could try and use Wireshark (or tcpdump) to confirm this by dumping the packets.
As to why you can't use it with cURL, I think it may be the version of cURL your Mac ships with. I don't quite know how the mac package system works, try and see if you can determine which OpenSSL your cURL is using. Does mac have something like strace perhaps?
Activity
ckcr4lyf commentedon May 23, 2023
This would be super useful, just running into this with node today and would be neat to have a solid reproducible testcase / domain.
ckcr4lyf commentedon May 23, 2023
@graingert FWIW I wrote a small program in node which returns the "bad" ServerHello via pure TCP, for any data sent to it: https://github.com/ckcr4lyf/no-rfc5746/blob/23c9abf620b37754a8eb4c206e6c8d37646a7c91/server.mjs#L15
For most TLS clients, they would send a ClientHello, this program returns the ServerHello not supporting the extension, causing failure.
Example run w/ curl, openssl s_client: https://github.com/ckcr4lyf/no-rfc5746/actions/runs/5060085504/jobs/9082507997#step:5:30
christhompson commentedon May 23, 2023
If this is relatively straightforward to configure in nginx, then I'd be happy to take a PR adding a new subdomain for this (or a snippet of nginx configuration I could use to set one up when I have a chance). New purely server-config tests are pretty easy to support (versus ones that require new and funky certificates).
ckcr4lyf commentedon May 23, 2023
I tried to look at it via nginx, it does not seem trivial. I had much difficulty implementing it myself since it seems TLS libs like OpenSSL don't expose it, and had to fall back to just mocking a packet via Raw TCP.
ckcr4lyf commentedon May 23, 2023
It doesn't seem like any of the tests have an "Actual" backend, so it's probably not a good fit...
christhompson commentedon May 23, 2023
Ah yeah if it requires the server misbehaving in a way that OpenSSL doesn't directly support, then it's likely that we can't do it on badssl.com as the overhead of running custom server daemons is too much. We rely on static nginx configurations (and some weird edge case certificates) to do all the work for us.
ckcr4lyf commentedon May 23, 2023
I'm hosting a "community server" for this if anyone wants to test: https://rfc5746.mywaifu.best:4433 (note the port). It's running on Oracle free tier, will try to keep it up.
gorkemhacioglu commentedon Feb 2, 2024
It is kinda hanging at this step. Any toughts?
ckcr4lyf commentedon Feb 2, 2024
I just tried it, seems to work. What is the exact command you're trying? The tool I wrote to replicate is very hacky, so it may not work unless you're explicitly using HTTPS.
gorkemhacioglu commentedon Feb 12, 2024
^^ Hangs :(
s_client -connectworks 👍I can not access through the browser. Is it an expected behaviour?
ckcr4lyf commentedon Feb 13, 2024
Which OS are you using? One guess I have is the cURL command is not using OpenSSL but something else (an earlier log you posted mentioned SChannel, which is Windows). I have only tested it via cURL + OpenSSL.
On a browser I don't expect it to work, since I think the TLS handshake fails at such an early stage that a browser won't show any error in particular.
However, you could try and use Wireshark (or tcpdump) to confirm this by dumping the packets.
gorkemhacioglu commentedon Feb 13, 2024
macOS. If I use latest version OpenSSL, is it not possible to test this?
ckcr4lyf commentedon Feb 14, 2024
I'm pretty sure on Arch I'm using the latest OpenSSL already:
As to why you can't use it with cURL, I think it may be the version of cURL your Mac ships with. I don't quite know how the mac package system works, try and see if you can determine which OpenSSL your cURL is using. Does mac have something like strace perhaps?