Difference between revisions of "Decrypt SSL (trusted man-in-the-middle technique)"

From WebOS Internals
Jump to navigation Jump to search
(New page: At times, it can be useful to sniff or intercept and decode communications from the pre / webOS client and its backend web services. As many of them utilize SSL for security, however, thi...)
 
m (fixed a link)
 
Line 3: Line 3:
 
The following is a method that can be used to set up a tunnel for an SSL site which you can then sniff and decrypt to observe the traffic in the clear.  This example will demonstrate decrypting the HTTPS transactions to ps.palmws.com (the patch service used in the update process)
 
The following is a method that can be used to set up a tunnel for an SSL site which you can then sniff and decrypt to observe the traffic in the clear.  This example will demonstrate decrypting the HTTPS transactions to ps.palmws.com (the patch service used in the update process)
  
This method has been successfully used to obtain traces of conversations with the update server, excerpts of which are posted in [[[ update-service-trace ]]]
+
This method has been successfully used to obtain traces of conversations with the update server, excerpts of which are posted in [[ Update_Service_Trace ]]
  
 
'''Install stunnel'''
 
'''Install stunnel'''

Latest revision as of 22:43, 20 March 2011

At times, it can be useful to sniff or intercept and decode communications from the pre / webOS client and its backend web services. As many of them utilize SSL for security, however, this can make it difficult for us to observe the actual HTTP transactions between the pre and these services.

The following is a method that can be used to set up a tunnel for an SSL site which you can then sniff and decrypt to observe the traffic in the clear. This example will demonstrate decrypting the HTTPS transactions to ps.palmws.com (the patch service used in the update process)

This method has been successfully used to obtain traces of conversations with the update server, excerpts of which are posted in Update_Service_Trace

Install stunnel

Ensure that you have installed stunnel on a designated man-in-the-middle server, which should be another system reachable by the pre, over a network interface that you will sniff (capture packets from for decryption) in later steps. Stunnel can be installed with "apt-get install stunnel" on debian / ubuntu or built from source code which can be downloaded from stunnel.org.

Generate CA and server certificates

First, download the script "cert.sh" from the (OWASP webscarab project.)

This script will create a directory called "sslcerts" in the current directory, generate / self-sign a Certificate Authority certificate and then use it to sign a certificate for the hostname you specify.

wget -O cert.sh 'http://dawes.za.net/gitweb.cgi?p=rogan/webscarab/webscarab.git;a=blob_plain;f=doc/cert.sh;hb=master'
sh cert.sh ps.palmws.com
cat sslcerts/ps.palmws.com-cert.pem  sslcerts/private/ps.palmws.com-key.pem > ps.pem


Set up the tunnel

Next, we'll set up a transparent SSL to SSL tunnel. Port 443 on your server will foward to ps.palmws.com but since your listener uses your cert/key for the client connection, you can use that key to decrypt any of that traffic.

Listen on local IP and de-SSL traffic to localhost:8080

sudo stunnel -p ps.pem -d 443 -r 8080

Listen on 8080, re-SSL to remote server on 443

sudo stunnel -c -d 8080 -r ps.palmws.com:443

Repoint your pre to use the tunnel endpoint as its patch server


Now you need to force the pre to use your man in the middle as ps.palmws.com. To do so, run the following command on the pre (as root):

echo "192.168.0.1 ps.palmws.com" >> /etc/hosts

192.168.0.1 is my server's IP address on a usbnet connection. Replace this with your own server's IP on wifi, usbnet, etc.


Make the pre trust your CA certificate


Now the pre is configured to connect to the man-in-the-middle / tunnel server and the tunnel server will accept an SSL connection from the client and initiat another one on the backend to the real ps.palmws.com server, forwarding traffic between them.

Unfortunately, your ps.palmws.com certificate has not been signed by any known / trusted certifying authority, so, once connected to your MITM server, the Pre will reject its certificate and cancel the update.

To enable your certificate to be considered trusted, your must install the Certificate Authority certificate that signed it (the one we generated earlier) into the trusted root / CA certificate store on the pre.

First, copy sslcerts/ca_cert.pem to your pre.

Then, on your pre, add the contents of that certificate to the certificate store. (run all these commands as root, ie "sudo su -" first, then cd to the directory where you stored ca_cert.pem):

CERTSTORE=/etc/ssl/certs/ca-certificates.crt
openssl x509 -in ca_cert.pem -text -noout|grep Subject:|sed 's/.*Subject: /subject= \//;s/, /\//g' >> $CERTSTORE
grep '==='  $CERTSTORE | head -1  >> $CERTSTORE
openssl x509 -in ca_cert.pem >> $CERTSTORE
echo >> $CERTSTORE


Sniff the traffic and decrypt it using our private key

Now sniff the traffic between the phone and your server. I use WireShark on the PC running the server which is connected to the pre over usbnet.

Wireshark supports decryption of SSL traffic if you have the private key. See WireShark's SSL page for details. The binding to enter in the SSL decoding (edit, preferences, protocols, SSL) is

192.168.0.1,443,http,/path/to/ps.pem

Or on Windows:

192.168.0.1,443,http,c:\path\to\ps.pem

(replace 192.168.0.1 with your man-in-the-middle server IP address)


With Wireshark running and decrypting all the traffic sent to the tunnel, you should be able to run the update app and watch the communications between your pre and the update service.

About:

- destinal - initial method and documentation