As a form of term paper for the Computers and Networks Security class at Roma Tre University, students have been asked this year to contribute to a wiki. I obviously picked the class and I’ve been assigned to a group in charge to write a threats analysis over the SSL / TLS protocol. Since I already had a look at presentations by independent researcher Moxie Marlinspike, I wrote an hopefully detailed report of the attacks he presented at Defcon17 last August. I discussed this report few days ago and since the wiki will be probably kept private for students, i’m going to publish this relation here, that follows.

SSL / TLS

Secure Sockets Layer (SSL) and its successor Transport Layer Security TLS are cryptographic protocols that aim to provide security for data transmitted over networks.
While the SSL wording refers to the original specifications developed by Netscape Corporation , TLS is an IETF standard, last updated in rfc2546, that anyway is based on the SSL specification, explaining why the word ”SSL” is often used to indicate the actual TLS protocol.
While the protocol is widely used to secure overlaying application level insecure protocols, such as HTTP, FTP, SMTP or VoIP applications, it may be used to secure tunneling virtually any other protocol.

Read more

In order to request a signed SSL/TLS certificate you have to send the Certification Authority a  proper formed request often indicated just as “CSR” together with the other details.
If you are  using Apache you can generate your passphrase-protected RSA 1024 bit key using  openssl with:

openssl genrsa -des3 -out your.host.tld.key 1024

And then generate the CSR to send ‘em, again using openssl with:

openssl req -new -key your.host.tld.key -out your.host.tld.csr

You will be prompted for some information that must be included in the CSR itself, and in short it will be done.

So Alice returned from wonderland to her dark and unsecure world, without sendig Bob the awaited postcard, that may be a big deal for their friendship, unless Alice keep with her an ssh access to the wonderland:

ssh alice@wonderland -L [<alice-bind-addr>:]<alice-port>:<bob>:<bob-port>

That will please Alice for a while since if her postcard is sent out from the <alice-port> it’s gonna be forwarded to wonderland over a (supposed) secure channel and then sent to Bob, but blues is aroud the corner because she’s now used to be carefree using her unsecure application protocol from wonderland and she doesn’t want to set up forwarding for each of her friends. Anyway, she may be fine using ssh as a SOCKS server reached over the secure channel with:

ssh alice@wonderland -D [<alice-bind-address>:]<alice-port>