Here is the demo recorded in the context of the SSL Threat Analysis i wrote about previously.

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

I have been recently asked to deliver a lesson in the base linux course LUG Roma3, which I cooperate with, is keeping at roma3 university on voluntary base.
Here are the slide I sketched out for this occasion.

I delivered a similar lesson on last edition of this course and also wrote a paper from what I presented at that time, but I think this pack is definitely better, and less boring than a long paper, so i’m removing the old post in behalf of this new one =)

When you have to locally manage scrap metals, it doesn’t matter if you are connecting a  microwave oven or a dozen of thousands bucks value brand new router or firewall, you will  probably do that over a serial cable. Devices likely offers a port labeled CONSOLE or  whatever you should connect the cable to. The cable type is device-dependent, but it usually  ends up with a serial connector for a serial port. If your computer doesn’t have that port, you  will need an adapter and its driver, such as to an USB port. While in linux you just modprobe the usbserial module with the appropriate vendor and product code, such as:

modprobe usbserial vendor=0xVID product=0xPID

for osx you may need the adapter drivers from the vendor ( they should be available on the vendor’s site, otherwise change vendor =P ). However, when the cable is plugged, you should find the proper entry for the (adapter) device, named tty.<whatever>

ls -1 /dev/tty.*

Now you will need to attach a terminal emulator to the found serial port to access the connected device console. On Mac Os X, as linux users will like, minicom is one of the best choices. Install it via MacPorts or Fink, then use:

minicom -s

to edit the default /opt/local/etc/minirc.dfl config file or to generate configurations that will be saved to /opt/local/etc/minirc.<your-config-name>. You should at least specify the port, baudrate, data bits, parity, stop bits and flow control. These are often indicated in the machine specs, with strings like the common 9600/8N1.

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>