Open marty1885 opened 1 year ago
NVM, I found there's the botan tls_server
command. And that with my certs work. My TLS server has some issues.
Nevertheless: Judging from your log transcripts, I don't think your certificate is the problem. The client complains that the server selected a TLS cipher suite that does not allow RSA as signature algorithm. Maybe you excluded all such cipher suites by accident? E.g. via configuring Policy::allowed_signature_methods()
or ::allowed_signature_schemes()
or ::allowed_signature_hashes()
.
No, I'm using Botan::TLS::Default_Policy
. I noticed the [tls_alert] tls_alert: illegal_parameter
also shows up when I try to connect using openssl s_client
. Does the issue sound familiar to you by chance?
I have ASan running. So can't be a buffer overflow somewhere messing this up.
No, it doesn't sound familiar but might be worth looking into. Are you using a stable version of Botan or latest master?
I'm using 2.19.3
Mhh, and I guess you just adapted an example to work with your network stack, right? I'd like to try and reproduce this. Or is this public code that you can share somewhere?
Yeah, I adapted the example on that page. Sorry for the late reply and thanks for your help, I was wiresharking too see if I can resolve it on my own.
The code is available here https://github.com/an-tao/trantor/pull/238. Code is a bit messy now as I haven't get to clean it yet. All Botan related code lives in trantor/net/inner/BotanTLSConnectionImpl.cc
and the respective header. To replicate it run
Build:
git clone https://github.com/an-tao/trantor
git checkout tcpconnectionimpl-rewrite
mkdir build
cmake .. -DBUILD_TESTING=ON -DTRANTOR_PREFERED_TLS_PROVIDER="botan" -DCMAKE_BUILD_TYPE=Debug
make -j
Generate certificate (name should be server.cert
and server.key
)
openssl req -new -newkey rsa:2048 -nodes -keyout server.key -out server.csr --subj '/C=TW/ST=Taipei/L=Taipei/O=Martin/OU=Martin/CN=Martin'
openssl req -x509 -days 365 -in server.csr -signkey server.key -out server.cert -extensions v3_req -extfile <(echo -e "subjectAltName=DNS:localhost\nkeyUsage=digitalSignature,keyEncipherment\nextendedKeyUsage=serverAuth")
And run
# The TLS server that's causing issue. It'll print logs to console if CMake is in debug mode
./trantor/tests/ssl_server_test
# In another terminal
openssl s_client -connect localhost:8888 -tls1_2
I'm able to reproduce this. The server indeed selects the wrong ciphersuite for the certificate. My openssl s_client
offers a long list of suites (including ones that would support RSA certificates for signing). But the Botan server implementation selected cc a9 - ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
which expects an ECDSA certificate. So openssl s_client
is right to complain.
Looking into it.
Found it! You tripped over a footgun in Botan's API. After applying this patch (and commenting out some faulty code in your override of tls_session_established
) I managed to successfully establish a connection with openssl s_client
and receive "Hello world". 😃
The issue is that Botan::TLS::Credentials_Manager::cert_chain()
has a footgun. The TLS implementation tells you which cert_key_types
it would like to receive. And it asks you three times (once for each RSA
, ECDSA
and DSA
). Unfortunately, things get messed up if you're "lying" about the requested key type by just returning your certificate. As a result, the TLS implementation wrongly selected an ECDSA ciphersuite (believing you provided an ECDSA certificate) and OpenSSL (as well as the Botan-Client 🤡) rightfully complained about that.
@randombit Should we give this part of the Credentials_Manager
some TLC before Botan 3.0 is coming out? Frankly, I was wondering about its design anyway. Particularly the ::cert_chain_single_type()
indirection.
@reneme Sounds good to me. I'll take a look if I have time but this is iffy for me, at least within the next week.
@reneme Thanks! That would have took me ages to figure out. You are a savior.
Not sure if it'll be helpful. IMO it'll be good to update the document and the repo's example code to include the handling of this behavior. So others will see how to correctly handle it upon first look at the doc. I can make the changes if this sounds like a good idea.
Hi,
Sorry I have to ask here. I've searched and can't figure this out. I'm adding Botan as an alternative TLS provider to a networking library I maintain. I got both Botan's TLS server and client to work separately (I confirm this by pointing the client to Nginx and server can be accessed from ncat). However I can't get Botan's TLS client and server to talk to each other. Here's some relevant logs
Server:
Client
These lead me to believe this is a certificate issue. But I checked I'm using x509 v3 with
X509v3 Extended Key Usage
set toTLS Web Server Authentication, TLS Web Client Authentication
via the following commandAnd I've confirmed it is V3 and with the correct key usage.
How do I generate a cert that Botan will accept?