search

chromium / badssl.com

:lock: Memorable site for testing clients against bad SSL configs.
https://badssl.com
Apache License 2.0
2.78k stars 187 forks source link

feature request: server that does not support the Renegotiation Indication Extension (RFC 5746) #507

Open graingert opened 2 years ago

graingert commented 2 years ago

so I can test configuration of openssl clients with UNSAFE_LEGACY_RENEGOTIATION_DISABLED

ckcr4lyf commented 1 year ago

This would be super useful, just running into this with node today and would be neat to have a solid reproducible testcase / domain.

ckcr4lyf commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

It doesn't seem like any of the tests have an "Actual" backend, so it's probably not a good fit...

christhompson commented 1 year ago

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 commented 1 year ago

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.

$ curl -v https://rfc5746.mywaifu.best:4433
*   Trying 152.67.8.255:4433...
* Connected to rfc5746.mywaifu.best (152.67.8.255) port 4433 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: none
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (OUT), TLS alert, handshake failure (552):
* OpenSSL/3.0.8: error:0A000152:SSL routines::unsafe legacy renegotiation disabled
* Closing connection 0
curl: (35) OpenSSL/3.0.8: error:0A000152:SSL routines::unsafe legacy renegotiation disabled
gorkemhacioglu commented 5 months ago

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.

$ curl -v https://rfc5746.mywaifu.best:4433
*   Trying 152.67.8.255:4433...
* Connected to rfc5746.mywaifu.best (152.67.8.255) port 4433 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: none
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (OUT), TLS alert, handshake failure (552):
* OpenSSL/3.0.8: error:0A000152:SSL routines::unsafe legacy renegotiation disabled
* Closing connection 0
curl: (35) OpenSSL/3.0.8: error:0A000152:SSL routines::unsafe legacy renegotiation disabled

It is kinda hanging at this step. Any toughts?


*   Trying 152.67.8.255:4433...
* Connected to rfc5746.mywaifu.best (152.67.8.255) port 4433
* schannel: disabled automatic use of client certificate
* ALPN: curl offers http/1.1```
ckcr4lyf commented 5 months ago

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.

$ curl -v https://rfc5746.mywaifu.best:4433
* Host rfc5746.mywaifu.best:4433 was resolved.
* IPv6: (none)
* IPv4: 152.67.8.255
*   Trying 152.67.8.255:4433...
* Connected to rfc5746.mywaifu.best (152.67.8.255) port 4433
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: none
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (OUT), TLS alert, handshake failure (552):
* OpenSSL/3.2.0: error:0A000152:SSL routines::unsafe legacy renegotiation disabled
* Closing connection
curl: (35) OpenSSL/3.2.0: error:0A000152:SSL routines::unsafe legacy renegotiation disabled
$ openssl s_client -connect rfc5746.mywaifu.best:4433
Connecting to 152.67.8.255
CONNECTED(00000003)
4037F9F379730000:error:0A000152:SSL routines:final_renegotiate:unsafe legacy renegotiation disabled:ssl/statem/extensions.c:945:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 49 bytes and written 335 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1706833804
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
---
gorkemhacioglu commented 4 months ago 
-curl -v https://rfc5746.mywaifu.best:4433
Trying 152.67.8.255:4433...
Connected to rfc5746.mywaifu.best (152.67.8.255) port 4433
ALPN: curl offers h2,http/1.1
(304) (OUT), TLS handshake, Client hello (1):
CAfile: /etc/ssl/cert.pem
CApath: none
(304) (IN), TLS handshake, Server hello (2):

^^ Hangs :(

s_client -connect works 👍 I can not access through the browser. Is it an expected behaviour?

ckcr4lyf commented 4 months ago

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 commented 4 months ago

macOS. If I use latest version OpenSSL, is it not possible to test this?

ckcr4lyf commented 4 months ago

macOS. If I use latest version OpenSSL, is it not possible to test this?

I'm pretty sure on Arch I'm using the latest OpenSSL already:

$ curl -V
curl 8.6.0 (x86_64-pc-linux-gnu) libcurl/8.6.0 OpenSSL/3.2.1 zlib/1.3.1 brotli/1.1.0 zstd/1.5.5 libidn2/2.3.7 libpsl/0.21.2 libssh2/1.11.0 nghttp2/1.59.0 nghttp3/1.1.0
Release-Date: 2024-01-31
Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTP3 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM PSL SPNEGO SSL threadsafe TLS-SRP UnixSockets zstd

$ openssl version
OpenSSL 3.2.1 30 Jan 2024 (Library: OpenSSL 3.2.1 30 Jan 2024)

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?