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.
Related
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.
How can I expand OpenSSL in Linux so that it can implement Pairing-based Cryptography? I am doing my thesis and this is the final part of it. I am guessing I need to find pairing based cryptographic libraries that can work within OpenSSL? Please help
I have multiple applications which work with one centralized Oracle database.
The applications are targeted on following platforms:
iPhone
Android
Windows (XP, Vista and 7)
Linux
Mac Os
Web applications (ASP.NET, PHP and JSP)
I want to know which kind of cipher I should use to make sure all my encrypted data will be readable (decrypted) for all my application
E.g. 3DES or RIJNDAEL_256 or TWOFISH256?
You should be able to implement those ciphers on all of the target platforms you mentioned.
As for which to use, I'd suggest Rijndael (AES) since it has received a lot of attention and has a proven security track-record.
http://gpg4browsers.recurity.com/ has JS implementations for all ciphers you mentioned.
All OSes you mentioned support all of these ciphers either directly or via mcrypt.
This reduces the question to opinionizing: So here is my opinion - do NOT standardize (in the sense of hardcode) to any of those ciphers, but invest the on-time penalty to develop your apps and protocols in a way, that allows them to handshake the cipher used. This way you can trade speed for security now and are open for developments in cryptography (or cryptanalysis)
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.