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.
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.
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.
How to enable the support of SSLV3 request in libcurl if it is disabled by default? I have found this on internet. https://curl.haxx.se/mail/lib-2015-01/0005.html.
How to use the patch available in this site? Or if there is any other way to achieve this then please guide?
SSLv3 is insecure
curl supports SSLv3 out of the box. Your SSL library may not though. I don't think any modern TLS library does. And if curl is built to support it, you must explicitly ask curl to allow it at run-time since the default will be TLS by default.
If you for example want to use with OpenSSL you need to build OpenSSL and explicitly ask it to enable SSLv3 in the config as otherwise it will not support SSLv3.
SSLv3 is inherently insecure and there's nothing we can do to fix that in the protocol. That's why everyone avoids touching it and have moved on. Going with SSLv3 in 2019 is a mistake. Don't go there. Argue with your boss, stand your ground.
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
I'm building a cross-platform app that will communicate with the server. Security is very important.
Is there a scheme that will allow me to "trust" that the executable is genuine and hasn't been tampered with and that the requests are indeed coming from my signed executable and not an impersonator? Seems like the traditional man-in-the-middle attack. How can I prevent it?
I understand that I can sign an executable with a trusted CA under Windows. This ensures that the executable hasn't been tampered with on the user's machine. However, a targeted virus can still replace the executable (as opposed to modifying it) with an impersonator and Windows won't complain.
Can, then, my genuine executable sign the requests it is making to the server and can I validate these requests on the server? The naive solution is to embed a "private certificate" in the signed executable. However, I suspect that it's possible to extract this private certificate even from a signed executable.
Finally, are there executable signing mechanisms in OSX and Linux?
For code signing on Mac there are some reference in StackOverflow here and here. I've seen different things for Linux like signelf, bsign (used by digsig), elfsign.
As mentioned by Nickolay O., code signing will not do anything against decompilation. Code signing doesn't prevent man-in-the-middle and it's not a solution to demonstrate to a server that the client hasn't been tampered with.
Signing executables has meaning only for OS - to let it know, that executable is a good one.
If somebody can decompile your application, than you cannot be sure in any way that request was sent by the valid executable.