TLS decryption using Wireshark: Where to find RSA key? - rsa

I am capturing network packets using wireshark and I need to decrypt TLS traffic. There is a procedure to be followed as mentioned on many websites check here.
There is a step mentioned to add RSA key while editing preferences for TLS however I am not able to find the key itself. Where can I find this key?

Related

Recording full https session and veryfication of recorded sessions [duplicate]

Is there any way that I can create a proof of a file downloaded using https? With proof I mean a cryptographic record of some sort that links the contents of a file to a site at a certain time. If I understand TLS correctly, the server certificate is only used as a basis to establish a session key that is known to both parties, so each request is not signed but just encrypted for transfer. Any ideas if this can be done and if so how?
In HTTPS the certificate is only used for authentication and with the obsolete RSA key exchange also for key exchange. Application data are only protected against modification by some man in the middle but they are not signed by the sender. While a HTTP server could be explicitly implemented to sign and timestamp the content, one can not enforce such operation against an arbitrary existing server.
For more see
Where in a TLS connection can I get the signature of the content sent by the server?
Why does HTTPS not support non-repudiation?
How to prove some server sent some file over HTTPS
Proving authenticity of data accessed over TLS by an untrusted third party

PostgreSQL SSL setup DigitalOcean

I am trying to connect pgAdmin to digitalOcean. However I am getting this error:
I add the certificate but digital ocean didn't provided me a key file.
Where could I find it?
This Is how I add the certificate file.
Thank you,
Jonathan Prieto
I think that the certificate that DigitalOcean provided is for the “Root certificate” field.
It is to verify the server, not to authenticate the client.
With the default configuration of libpq you don't need the certificate at all, and SSL is used only to encrypt the communication.
You need to create this private key with openssl command.
Unfortunately client certificate setup is not documented in the PostgreSQL official documentation.
The best documentation that I have found is the following:
https://info.crunchydata.com/blog/ssl-certificate-authentication-postgresql-docker-containers.
You should try to adapt "Step 4: Generating the Client Key and Certificate" to your configuration.

Secure alternatives to fingerprint-verified TLS on ESP8266 for MQTT or REST communications?

MQTT or REST from an ESP8266 without TLS is risky. Passing unencrypted credentials and tokens around doesn't strike me as being terribly secure. But TLS communications on the ESP8266 requires a large chunk of memory, and to avoid man-in-the-middle attacks you really have to verify the server certificate, generally done using an SHA1 fingerprint. But the SHA1 fingerprint will change as the server certificate changes, so hard-coding it isn't an option. Asking a user to go and find their SHA1 certificate fingerprint using their browser dev tools and insert it into a web config portal is pretty much a no-no too.
Has anyone come up with a workable solution to this conundrum? One which delivers excellent security with greatest genericity, soft settings and least user-involvement? What's the best way of effortlessly achieving a high level of security for outside-firewall communications on an ESP8266?
The ESP8266 Arduino project introduced verifying with root CA certificates which is heaps better than using fingerprints. They have an example of it for GitHub here: https://github.com/esp8266/Arduino/tree/master/libraries/ESP8266WiFi/examples/HTTPSRequestCACert

Whether Network Admin will be able to see my request even in the TLS configured area

I have configured a web application with TLS 1.0. My requests are going in the encrypted format through out the channel, which is secured for from the man in the middle attack. TLS is working on RSA mechanism, so the doubt is if the network admin (having the private key) will be able to decrypt the request or not.
First, system or network admin do not have access to the private key if you add an HSM and configure your web server to use it (see https://en.wikipedia.org/wiki/Hardware_security_module).
Secondly, many PFS cipher suites are available with TLS 1.0 (see https://security.stackexchange.com/questions/74270/which-forward-secrecy-cipher-suites-are-supported-for-tls1-0-protocols), so if you only accept such cipher suites on your web server, somebody that can capture your communications and that knows the RSA private key will not be able to decrypt the content of the channel: the cipher key used to protect the channel is ephemeral, it is not your RSA private key.

SSL in a REST Lift project, where to start?

We are doing a project in Scala, using Lift to provide some REST style web services for clients (Java-script through AJAX). For some business reasons we decided to put it all under SSL but I'm am not sure where to start. Insights would be much appreciated.
Whatever server software is currently handling HTTP traffic (e.g. Jetty, Nginx, Apache...) almost certainly has some means of adding SSL support and disabling plain HTTP; try that first.
As for the basic mechanism of adding SSL support, it goes something like this:
Generate an RSA keypair (the key size should be at least 1024 bits). This step should prompt you to fill in some information about you, your organization, and the server's hostname ("common name" in X.509 parlance). It should also prompt you for a passphrase, which will be used to encrypt the private key.
The keypair consists of a private key (this is the part you shouldn't share with anyone) and a self-signed certificate, which contains, along with other metadata, the public key.
If you want to get a real cartel-signed SSL certificate, so that members of the general public won't see nasty warnings when they visit your site, you'll need to generate a Certificate Signing Request (CSR) from your keypair and submit that to an SSL certificate authority, who will create a certificate derived from your CSR, but signed with their private key. Luckily, in recent years, the SSL CA business has gotten extremely competitive, so pricing shouldn't be a major hurdle anymore.
If you're not planning to get a real cartel-signed SSL certificate, you can use the private key and self-signed cert as-is.
Either way, you need to tell your web server how to find the certificate (whether self-signed or CA-signed) and private key. Apache HTTPD prefers to keep the two things in separate files; most JVM servers prefer that they be encapsulated in a keystore. The best keystore format for general use is called PKCS#12, it's an industry standard. Making a PKCS#12 file out of a separate key and cert is a bit tricky, look on ServerFault if you can't figure it out. :)
You usually want to put the private key passphrase in the server's configuration file, so make sure that configuration file (and the file containing the private key) have the most restrictive permissions that will still work.
This depend on which application server you're running.
Jetty: http://docs.codehaus.org/display/JETTY/How+to+configure+SSL
Tomcat: http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html
Glassfish v2: http://blogs.oracle.com/enterprisetechtips/entry/using_ssl_with_glassfish_v2
Glassfish v3: http://javadude.wordpress.com/2010/04/06/getting-started-with-glassfish-v3-and-ssl/
You're not sure where to start with which bit? The SSL?
Set up stunnel (or similar) in front of your webapp, and firewall your webapp off so that only stunnel can access it. Then your clients can only access your webapp over SSL, via stunnel.