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
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.
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'm trying to develop a kind of security program on Linux. So, My plan is currently to use AES128bit-CBC. I heard AES 128 is basically supported on OSX. Is there any libraries on Linux like that?
The libcrypto library in the OpenSSL package supports AES128 encryption. Most Linux distributions like RHEL, SuSE and ubuntu come with OpenSSL.
The AES_set_encrypt_key() and AES_cbc_encrypt() functions from <openssl/aes.h> implement the function you're after.
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.