On 2022-12-11, Alceu Rodrigues de Freitas Junior <glasswal...@yahoo.com.br> wrote: > > > Em 11/12/2022 07:34, Stuart Henderson escreveu: >> On 2022-12-10, Alceu Rodrigues de Freitas Junior <glasswal...@yahoo.com.br> >> wrote: >>> If I read correctly, the Mikrotik is using an SSLv3 certificate, which I >>> guess shouldn't be in use anymore. >> >> There's no such thing as "an SSLv3 certificate", they are all just X.509 >> certs. The sslv3 refers to the type of alert, sslv3 alerts are still >> used in TLS; SSLv3 itself hasn't been supported for years. > > That's quite confusing. Since SSL v3 was deprecated, I assumed the > mentioned router was quite old and that's the reason it was failing with > newer versions of OpenBSD.
TLS is a large and complicated protocol, with some new bits but also some old bits carried through from SSL, not everything xhanged. >> It doesn't necessarily use a certificate anyway, it may well be using >> ADH for this. Federico, do you have a cert configured for the api-ssl >> service on the routeros device, in "/ip service print"? > > And now I'm even more confused, looks like I'm still can't get my head > around OpenSSL. Looking at here: > > https://www.openssl.org/docs/manmaster/man1/openssl-ciphers.html#CIPHER-STRINGS > > The certificate may define the ciphers it accepts, but what does it mean > "It doesn't necessarily use a certificate anyway" and it's relation with > ADH cipher? ADH (Anonymous Diffie-Hellman key exchange) provides a comms channel that is secure to passive eavesdroppers, but doesn't provide authenticity (no proof that you're communicating with who you think you are; someone who can respond to comms, i.e. an "active" attacker, can intercept the "secure" channel). The certificates in a "normal" TLS connection are there to allow one side to prove to the other that they're the expected endpoint; in that case an active attacker wouldn't be able to intercept comms without the real endpoints noticing (as long as they're checking certificates). The guarantee you get from ADH is roughly equivalent to what you'd get if the device generated a key and self-signed certificate and the other side didn't check the cert. So actually in many cases the device would do just that. But RouterOS didn't do that, and used ADH by default instead (they could have chosen to generate a key and self-signed certificate and use "normal" TLS for this api connection, but they didn't; however if you login to the router you can configure it to do that instead). >>> Em 10/12/2022 17:01, Federico Giannici escreveu: >>>> Since I upgraded from OpenBSD 7.1 to 7.2 (amd64) I'm no longer able to >>>> use IO::Socket::SSL perl library to connect to some devices (Mikrotik >>>> routers, via their API). >>>> >>>> This is the only debug info I was able to obtain: >>>> >>>> DEBUG: .../IO/Socket/SSL.pm:842: local error: SSL connect attempt failed >>>> error:14004410:SSL routines:CONNECT_CR_SRVR_HELLO:sslv3 alert handshake >>>> failure >> >> Maybe try connecting with openssl s_client too? That would help show if >> it's a problem specific to IO::Socket::SSL or something more general. >> >>>> Unfortunately it seems that both perl functions >>>> Net::SSLeay::set_security_level() and >>>> Net::SSLeay::CTX_set_security_level() don't work. I get the following >>>> error. Maybe they are not implemented in our version of Net::SSLeay perl >>>> library? >> >> The security level stuff was only recently added to libressl, it is still >> hidden behind #ifndef for libressl in p5-Net-SSLeay. I think you can set >> it in the ciphers string though, if it is ADH maybe you need something like >> "ADH:ALL:@SECLEVEL=0" (though in that case you would probably be better >> advised to generate and use certificates instead). > > I did some search and so I guess this relates to > https://www.openssl.org/docs/manmaster/man1/openssl-ciphers.html#CIPHER-STRINGS. > > Interesting that this can be set at IO::Socket::SSL but not (at least as > far as I could check) with Net::SSLeay, which is a dependency from the > former which let me understand that works at a lower level. There are multiple ways to set the "security level"; either at the same time as setting the cipher, or as a default for all operations. When set as part of the cipher the "cipher string" is passed through direct to the libressl (or openssl) libraries. When setting the default it uses a separate library function that Net::SSLeay does know about, but doesn't yet understand that it's available in libressl so doesn't expose it. > Finally, setting the security level to zero wouldn't increase the > chances of having issues since it allows poor options? Just checked that > in > https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_security_level.html Yes it certainly does. But considering what guarantees ADH is able to make (or more importantly _not_ make) you can see why it's disabled except at low security level. You don't want to be able to accidentally enable a cipher that also disables authentication. In particular, if a client was configured to allow anonymous DH, even if the server normally sends a certificate and the client checks certificates, a MITM could intercept the connection, negotiate ADH with the real client, and proxy the messages to a separate connection with the server, so the client would ne unaware of the problem. > My apologies if all this is too basic. Anyway good references would be > appreciated. While the DH key exchange is important to many encrypted comms protocols, I would expect that most people who have a rough idea of what SSL/TLS is normally used for haven't heard of ADH/AECDH and don't realise that TLS has a way to connect without using certificates. Some more info: https://en.m.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange https://wiki.openssl.org/index.php/Diffie_Hellman -- Please keep replies on the mailing list.
