I am using mitmproxy to log the tls 1.2 traffic of an IoT device.
The client device that just supports sha1 signature algorithms. If I am using mitmproxy v8.0.0 it works fine. If I update to a newer version, for ex. 9.0.0, I get the following error:
Client TLS handshake failed.
The client may not trust the proxy's certificate for
(OpenSSL Error(\[('SSL routines', 'tls1_set_server_sigalgs', 'no shared signature algorithms')\]))
If I check the communication with wireshark, I see that the sha1 signature algorithms are missing.
1
mitmproxy v8.0.0 uses beside others following dependencies:
"cryptography>=36,<37",
"pyOpenSSL>=21.0,<22.1",
mitmproxy v9.0.1
"cryptography>=38.0,<38.1",
"pyOpenSSL>=22.1,<22.2",
I already tried to use OpenSSL v1.1.1n by building the cryptography module 38.0.4 myself. (This is the same version used in mitmproxy v8.0.0) But the error still occurs. Thus lowering the pyOpenSSL/cryptography module version breaks mitmproxy v9.0.1 as it is using APIs from the newer module versions already.
If I also rebuild the cryptography module for 8.0.0 I will get the same problem. Maybe something is different with the systems (docker python:3.9-slim-bullseye) OpenSSL?
Is there a way to manipulate the signature algorithms directly? They seem to be either controlled by pyOpenSSL or cryptography, but I have no idea where I could change them, so the client can connect to my mitmproxy server.
The solution is to reconfigure the /etc/ssl/openssl.cnf for a lower SECLEVEL.
Add the following to the beginning:
openssl_conf = default_conf
And change the ending to:
[system_default_sect]
MinProtocol = TLSv1.2
CipherString = DEFAULT#SECLEVEL=1
Same problem as here
https://askubuntu.com/questions/1233186/ubuntu-20-04-how-to-set-lower-ssl-security-level
If you use the integrated OpenSSL within the cryptography module of python, it seems to have SHA-1 enabled by default. If you use the systems one by building the module yourself, it uses the systems OpenSSL library.
Related
I have a RHEL 8.6 system in FIPS mode that I'm testing what happens with containers and their runtimes when the host has FIPS=1. My expectation is that calling an unsupported cipher or method should throw some sort of error.
In my testing, I have built a NodeJS image that's been compiled with OpenSSL3.0.3 and can start the node runtime with or without fips using:
/opt/node/bin/node --force-fips test.js
or
/opt/node/bin/node test.js
When the code runs with --force-fips the program throws an error that I expect such as Error: error:0308010C:digital envelope routines::unsupported.
However, removing the --force-fips the code runs successfully and outputs an md5 hash /opt/node/bin/node md5.js b10a8db164e0754105b7a99be72e3fe5
Since the Host is in FIPS, I thought this would be passed through and block those unsupported mechanisms like MD5 being old/unsupported in FIPS or ChaCha20 being too new and unsupported/non-validated cryptography.
What benefit does the Host FIPS mode present if the runtime can still be using ciphers and cryptography that should ultimately fail?
The FIPS mode in the OS tells the OS-provided cryptographic libraries, such as OpenSSL, to use only FIPS-compatible ciphers and to perform additional tasks, such as a self-test on startup.
What it doesn't affect is third-party cryptographic libraries. For example, RHEL 8.6 comes with OpenSSL 1.1.1, but your Node version is likely using a statically-compiled 3.0.3 (which, given the history of necessary security updates to OpenSSL, seems like a bad idea). Thus, the OS didn't ship that cryptographic library and the FIPS mode of the OS wouldn't affect it.
Similarly, if you were writing Rust and used a Rust-based implementation of cryptography, or using the Go standard library for Go, then those also wouldn't be affected by the OS's FIPS mode.
What I expect to be happening here is that the host / OS is indeed just using FIPS ciphers. However, please understand that algorithms implemented in software are not detected by the OS in any way. Neither does it know about the force-fips option. So you need to configure them explicitly.
I am planning to implement a "simple" DTLS tool in python3, which is able to initiate (client) and accept DTLS (server) connections with a PSK as a PoC (later on i am planning to extend it to certificate-based authentication).
I spent days researching libraries that offer this functionality, but i am still not sure what to use. (Any wrapper/library suggestion with documentation/examples are more than welcome).
While it is straightforward to create the DTLS Clients/Servers with the openssl binaries (for example):
openssl s_server -dtls -accept 1337 -nocert -psk deadbeef -cipher PSK-AES128-CCM8
for the server (with a specific ciphersuite) and
openssl s_client -dtls -connect 127.0.0.1:1337 -psk deadbeef -cipher PSK-AES128-CCM8
for the client, i am struggling to find do this with python. (pyopenssl offers no DTLS support) Are there any concrete examples for an implementation using a widly supported library/wrapper? (There are some Coap/IoT libraries out there focussing on the client side (aiocoap), but for my idea it is neccessary to implement both sides)
I ended up using mbedTLS (former PolarSSL). They offer a quite extensive Python3 wrapper that offering almost all of mbedTLS functionality. The readme offers a very useful DTLS sample implementation featuring authentication using a psk and/or certs.
In all the tutorials which I saw in web, they pointed me to add key file in
Edit->Prefereces->Protocols->SSL->SSL key file
but there is no such SSL key file in version I use.
Can somebody guide how to decrypt SSL Traffic in wireshark 1.12.4 ?
It does not depend on the version of wireshark, but on the SSL lib it was compiled against.
In order to use it, you need to have a wireshark that was compiled using GnuTLS rather than OpenSSL or bsafe.
I need to secure my UDP traffic. As far as I understand DTLS protocol is the best way to do it. There is another one - IPsec - but it looks not applicable for me because it's not easy to use and there are possible hardware problems.
I've found that there are some libraries which have DTLS implemented. So now I'm trying to choose - OpenSSL or GnuTls? Could you please advise me what is better to use? What are drawbacks or advantages? Or may be there is another library with DTLS support implemented?
I've found the following facts about the libraries and DTLS.
There is another lib with DTLS support - CyaSSL, but it supports DTLS only in test mode for now.
Although RFC 4347 dates from Apr, 2006, the OpenSSL supports DTLS since 2005 (v0.9.8). Many Linux distribs include this version. OpenSSL API looks ugly a little, but it seems like DTLS implementation is stable.
GnuTls supports DTLS since 2011 (v3.0.0). Looks like no Linux includes this version yet. (For example, Ubuntu 11.04 uses v2.8.6, Ubuntu 11.10 is going to use v2.10.5, not v3.0.0.) There is no information about when v3.0 will be used. It can be built manually, however it depends on too many additional libraries which may have no native support in some distribs.
It looks like all of these libraries can be used on other platforms (e.g. Windows).
Known OpenSSL issue: OpenSSL has compression enabled by default for DTLS, but it shouldn't be. OpenSSL v0.9.8 API doesn't provide any method to disable compression. The method should be implemented manually.
SUMMARY:
Speaking about usability, personally I would prefer GnuTls API, but at the time OpenSSL looks more preferable to use.
IPsec is the oldest and hence most compatible and stable, but requires tasks from the sysadmin and can be quite challenging for novices. DTLS is tackling the problem from the application side which the programmer can significantly simplify and integrate with existing environments with less change.
The choice between OpenSSL and GnuTLS is almost always due to license.
OpenSSL license includes an advertising clause:
3. All advertising materials mentioning features or use of this *
software must display the following acknowledgment: * "This
product includes software developed by the OpenSSL Project * for
use in the OpenSSL Toolkit. (http://www.openssl.org/)"
GnuTLS from Wikipedia:
GnuTLS was initially created to allow applications of the GNU project
to use secure protocols such as TLS. Although OpenSSL already existed,
OpenSSL's license is not compatible with the GPL;[4] thus software
under the GPL, such as GNU software, could not use OpenSSL without
making a GPL linking exception.
http://en.wikipedia.org/wiki/GnuTLS
One obvious benefit seems to be the low level access you gain from using OpenSSL. But, I'd like to know if there's anything (important) that you can do with OpenSSL and not otherwise.
Secure Transport (the SSL/TLS implementation available on Mac OS X) is not available on iOS as of version 4.2.1. Third-party developers have to use the URL Loading System or CFNetwork (the latter optionally together with NSStream).
I checked this again and the only benefit of OpenSSL seems to be it's range of cipher suites supported. Also, OpenSSL gives you a much granular control of the entire process, but this may be superfluous for most applications.