The Value of Procedures and Fun with PCI and ISPs

While working with a prospect recently I was asked to help get a server up to speed to pass a PCI scan. I asked to see the report to get an understanding of how much work there would need to be done. In the initial report there were not too many things gone wrong, and basically what was in use was an SSL powered site on Linux and Apache. It was pretty straightforward stuff:

SSLversion 2 was enabled, medium to weak ciphers were in use. Typical things you would find on a server that's not been hardened.

So we discussed the situation, the work needed to be done, the time frame involved and we went on our way. For reference the so-called "Total Risk" calculation was not very high - it was something around 25 or so. The way this vendor had reported its overall risk of the server was to give each vulnerability a weight from one to 10, and then simply add up all the potential vulnerabilities.

Come to find out the client reran the PCI scan and now instead of having a "Total Risk" of 40 it was 108. Here's a mock of what that would that would have looked like (i.e. not the real report).

The main problem came in the fact that now instead of simply editing some Apache configuration files to make it use strong ciphers and strong versions of SSL, testing the new setup and documenting it, now the SSH Daemon and Apache were flagged to be upgraded as a resolution.

Again, really not a problem and really not a major reason for concern, except for the fact the correct method of updating the server packages was unknown. I did not want to move forward without knowing that, and in any case, any sort of validated backup and rollback procedures for any and all changes to a production instance.

Like anything else the best practice before diving headfirst into project is to understand the scope of the project, clearly define what needs to be done, and have a good ballpark of the time needed to take place.

Since there are many ways of updating packages on Linux my first task was to understand really how this server was should be properly updated (Most Shared and Dedicated ISPs used some sort of easy to use frontend to make this easy - others don't!). Recently I updated all of my binaries on my dedicated host and it only took a few minutes using apt-get. Apt-get dutifully stopped all the necessary services, updated what it needed and all was well. Of course I had a full image backup ready and waiting to go should anything happen.

My concern at this point for the client was that if I were to simply "make it happen" by downloading some software off the Internet, there may be some other problems introduced later for the client as you'll see.

A quick call to the ISP revealed "Plesk is crucial to all of the running services on the server. Specifically no one should go ahead and try to upgrade any services or software without using the Plesk control panel. Applications will break horribly if so." Ah, good to know, right?

To put it another way if I were to have jumped straight into the project, asking for root access and added RPMs or apt-get'd the box, it may actually worked - short term.

But the problem would have come long term, maybe a few weeks/months or longer when the client went to upgrade his system all sorts of version incompatibilities would have shown up and mayhem would have ensued. Bad Times!

Without an understanding of the overall potential risks involved, it's never wise to rush in. I used to work with a systems administrator who had the following tag line in his e-mail: "There are old administrators and there are bold administrators but there are no old, bold administrators."

Good advice kids!

Cain, rainbow tables, and NTLM hashes

Cain and Abel is a tool aimed at recovering a user's password from the hash located on a Windows system. That it is one of its features, but there are *many* more that you can read about at the tool's website.

This article is going to show up one method of how to use freely available tools to crack and audit window XP Windows passwords.

If you're approaching a standard windows XP machine the user's hashed credentials are stored in \windows\system32\config\SAM. If you fire up the Cain program, it will look there for the hashes for you:

I.E Navigate to the cracker tab and the appropriate NTLM hash screen and then click the on the + which will dump the local users hashes  into the program.

The next thing to do is to  select a user for whom you'd like to crack a password for. You'll have a few options, including dictionary attack, brute force attack, and cryptanalysis attack. If you're going to try the dictionary attack, you'll need to provide a good dictionary file. You can also choose a brute force attack, where the program will simply sequentially go through all the possible combinations/permutations of all the possible characters/passwords given a specific minimum and maximum password length.

Let's give the brute force method a shot first:

You can see here that I chose a minimum of one character and a maximum of 16 characters, and a pretty varied character set to try from. You can't see it here, but when I click on start,  the program tells me what current password it's trying, as it cycles through all of them. However what you can see is the time left until it finds the right one, which you can see here:

The program says it's going to take 1.68 X 10 raised the 17th power years.  That is a very long time to say the least - its much larger than a billion, much larger than a billion trillion years, so clearly it's time I upgraded my CPU or I tried a different method.


The other method we'll use is cryptanalysis attack. You can see how to select that option here:

Specifically we're going to make use of a Rainbow Table. A rainbow table is basically a database of hashes that are precomputed ahead of time so you don't have to wait to try every possible combination of password, wait for the system to hash it, and match it as we saw above.

You can find out all the technical details listed here in the paper "Making a Faster Cryptanalytic Time-Memory Trade-Off" by Philippe Oechslin. An excellent and perhaps more easily to follow article on rainbow tables could also be found here.

So now that you know what they are,  it's time to use them. You have a few options when using the rainbow tables: create them on your own or purchase them.

If you'd like to go ahead and purchase them I'd suggest stopping over at the Project Rainbow Crack website, and also read the following article by John Strand and his experiences.

It turns out it's really easy to create the rainbow tables and here's excellent article on how to do so specifically using the rtgen tool from the  Project Rainbow site.

Since I was using an older PC it took me about five days to completely create the rainbow tables that are described in the tutorial. I.E:

rtgen ntlm loweralpha-numeric 1 7 0 3800 33554432 0
rtgen ntlm loweralpha-numeric 1 7 1 3800 33554432 0
rtgen ntlm loweralpha-numeric 1 7 2 3800 33554432 0
rtgen ntlm loweralpha-numeric 1 7 3 3800 33554432 0
rtgen ntlm loweralpha-numeric 1 7 4 3800 33554432 0
rtgen ntlm loweralpha-numeric 1 7 5 3800 33554432 0


Specifically, 6 tables to crack an NTLM based hash using just the loweralpha-numeric character set with a minimum of one character at a maximum of seven characters per password.

So by now you're probably wondering, well did it work? What I did as a test is create 2 new local XP users and I gave the first one a password of john123, just within the limits of our character length.

Sure enough and just about 40 seconds Cain was able to recover the password with ease. I wasn't really convinced, I mean, I could have guessed 'john123' as easily as anyone so I tried a little bit more difficult password, still under the length limit.

As it turns out the password that I chose,  l0v33l , was even easier to crack in terms of overall time, mainly due to the fact it had one less character, but still was able to recover the password of what would seem to be a password that is not easily guessable.

Soon as you can see, there may be a decision in terms of should I buy or should I create my own rainbow tables, but the answer depends on the solution you're looking for. If you're looking to try to crack a password that definitely has a very varied character set, and known to be a good length  you might do better to simply purchase the tables since the tables themselves can get quite large, and as you've seen to simply create rainbow tables for a very small character set and small password lengths they can take a long time to create and also to download (should you find some online).

Finally, a helpful tool in determining table size is Winrtgen. What I like about the tool is that it clues you in on the success probability and the overall amount of space that you'll need to create the tables.
As you adjust the chain length, count,  and number of tables, winrtgen will show you the resulting probability of success and size of each table, which would be  considerations in your decisions:

Good Luck!

The Next Hope Part 2 - Saturday and Sunday Notes

Please see The Next Hope Part 1 - Friday Notes for the first day and summary of the HOPE conference.

Behind the Padlock: HTTPS Ubiquitous and Fragile - This was a talk was given by Seth Schoen

Some interesting topics were brought up, the Moxie Marlinspike null termination hack on SSL:
http://www.blackhat.com/presentations/bh-usa-09/MARLINSPIKE/BHUSA09-Marlinspike-DefeatSSL-SLIDES.pdf

CN NIC root edition was a interesting bit.
http://yro.slashdot.org/story/10/02/02/202238/Mozilla-Accepts-Chinese-CNNIC-Root-CA-Certificate

Check out Carnegie Mellon perspectives as a tool
http://www.cs.cmu.edu/~perspectives/firefox.html

as well as cert lock and HTTPS Everywhere - https://www.eff.org/https-everywhere

The author noted that DNSSec has now signed the root zone, which we hope will improve security there: http://gcn.com/articles/2010/07/19/dnssec-fully-deployed-at-internet-root.aspx

The Keynote Speech
This speech was given by one of the developers at the Tor project who also works at http://wikileaks.org/
That is the end of my notes on this topic.

How to make a living doing what you love -- this topic was given by Mitch Altman

The summary here was if you don't love you job, find a way to make money loving what you do. Mitch Altman is the inventor of TVBgone, and he shared with his story about how he came to create the product, get it to market, and how he made enough money to survive on it. Very close path to the Four Hour Work Week.

He was really gracious in sharing his time and seemed genuinely interested in helping anyone who wanted to "quit their job" and follow that dream.

The bottom line here was you are going to be spending a significant amount of time if you do follow your dream so why not love every minute of it and follow your passion! No real technical links here just a lot of inspiration.

Why you should be an Amateur -- this talk was given by Ben Jackson

At first my expectations for this talk were low, as I had no real interest in becoming an amateur radio operator. However as Ben Jackson is a very dynamic and humorous speaker, I must admit he got me curious about being an amateur radio operator, and if I find some time and little extra cash I may take him up on it.

One thing I had no idea about is that the "44-NET" IP address space is specifically for radio and are actually public routable IP addresses. Wow! Really cool: http://www.qsl.net/kb9mwr/projects/wireless/amprnet.html


To become an amateur radio operator, basically you need a basic radio kit, and to pass a test.
There are technician, general, and amateur classes, and they progress in difficulty and scope. However, most people with some basic understanding of electronics radio systems and so forth should be able to pass the first exam fairly easily: http://www.arrl.org/licensing-preparation-exams


Failing - Reach out and Touch Face - Johannes Grenzfurthne


This talk was about failing given by Johannes. I can not adequately describe exactly what I saw. Johannes is a combination of Carrot Top, Will Ferrell, and Gallagher. His talk was at once crazy, disheveled, awesome, and provoking. I really don't know what I saw but I know I was entertained!

He's the guy here: http://www.flickr.com/photos/laughingsquid/4803235314/

Social Engineering - this talk was presented by Bernie S. and other people who did not give their real first names and someone we all think of as a Legend.
Let's just say this was a talk about social engineering. That is all I'll say on the topic.


Radio reconnaissance and Penetration Testing - this talk was given by Matt Neely
This was a really fascinating talk, as Matt is penetration tester who's done a lot of on-site testing with radio equipment, wireless security and so forth.

One thing he brought up that was interesting is that jamming a signal is a illegal regardless if the statement of work you've obtained from your client says it's okay. Jamming is illegal as is illegally transmitting. Speak with your lawyer.

It's possible to relatively easily figure out what scanner frequency a company is using by simply googling for it. His suggestion for buying a good radio was first look for a good antenna, and then look for good radio.


Sunday

phone freaks - This talk was given by Phil Lapsley

This was another fascinating talk, it started from the incorporation and history of AT&T, Bell Labs, and the process that how hackers would initially social engineer the inward operator to make phone calls. The author is working on a book that hopefully will be out in 2011 regarding the history of phone freaking. It looks very interesting to me.

Some of the names he suggested to go to google were Joey Bubbles, John Draper and Evan Doreville.

This was a really well laid out talk as the author clearly has his thoughts together as he is soon to be published.


Track me not - This talk was given by Vincent Toubiana

Basically this utility will send queries to Google, using a DOM-based query that aims to replicate the exact usage of the user, making very hard to distinguish and profile a user's Web searches. A very interesting project with more information here: http://cs.nyu.edu/trackmenot/


The Freedom Box - this topic was given by James Vasile

This topic was raised to bring about a discussion to see if it would be possible to create some sort of Linux box, where all of the users' potentially sensitive data would be held such that it would be then somehow securely given out to only the proper parties. This was a interesting idea in theory, the author is looking for input on the actual deliverable.

Distributed Denial of Service - this talk was given by Alessio Pennasilico
This author, with a great Italian accent, shared his story about how his client was attacked through a distributed denial of service attack and his efforts to thwart it. The Long story really short he installed an open BSD firewall using the SYN-proxy feature and PF sync tools.

Unfortunately the author had bit of trouble as the ISP really had no interest in helping or were ill-equipped to do so. He also contacted some vendors to help scrub the traffic, but to no avail.

He noticed that the IP's kept changing every 15 minutes or so, so even if blocking were a valid solution, they would simply change after 15 minutes, and approximately 200 IP addresses were in the mix.

What I really liked is that the author really built up the story from 100 to 200 to 300 to 850 Mb per second of traffic and shared the actual technical challenges met and solutions employed to finally defeat the attacker. He had a really great attitude about it and was really willing to share his story.

The Black Suit Plan Isn't Working - Now What? - this talk was given by James Arlen

Basically this talk was suggested as a means to break an information security professional out of their funk. I liked that the author suggested that "we" were the ones that need to change (I.E look in the mirror first), and don't look at a business person to understand you, you should look at the business person and try to understand where they're coming from, and to speak in their language.

Only when we understand others and speak their language will we ever create a bridge of communication (my addition).

The Next Hope Part 1 - Friday Notes

I just came back from the HOPE 2010 conference, and now have the time to share my notes of those talks I attended.

For those of you who don't know the HOPE Conference is the Hackers on Planet Earth Conference, sponsored by the hacker magazine 2600: The Hacker Quarterly, where the conference content is devoted to security, freedom, and general fun hacking: http://thenexthope.org

Most conferences schedule speakers and then have 'lunch' or 'breaks'. Not HOPE. 10am to midnight/1am with quality talks. My head is 'full' with information, I absolutely loved every minute of it.

And the registration fee was only $100 at the door ($85 if pre-registering). Wow, what a value and service to the hacker community. Please consider supporting http://www.2600.com/ with a subscription!!

Here are my list of notes with extreme summaries pulling out most important points of each talk:

IPv6 - This talk was given by Joe Klein.
Basically we all know where running out of IP addresses using IP version 4, and IPv6 is the answer.

IPv6 address space provides the potential for a maximum of 2 raised to the 128th power, something like 340 billion billion billion billion addresses. Compare that to 2 raised to the 32nd power, 4,294,967,296, about 4.2 billion! See this link for more: http://geekswithblogs.net/devdevin/archive/2008/03/25/120750.aspx

Work is going on now to convert the IP space over to version 6, however most likely in the next 36 months will see a lot of work being devoted. So if you are a consultant, or contractor, this could be a great opportunity to get some solid work!

He brought up some good discussion items, like thinking about security on an IPv6 network, RFC 3756, definitions of trust models would be a good read.

References:

CALIPSO - Common Architecture Label IPv6 Security Option
http://www.rfc-editor.org/pipermail/rfc-dist/2009-July/002329.html
RFC 3756
http://www.ietf.org/rfc/rfc3756.txt

Location privacy - this talk was given by Ben Jackson

Ben has created http://icanstalku.com/which basically is downloading pictures from Twitter, extracting the geolocation tags, and putting them on the website to give those details out.

The intention of this program was to bring about security awareness and implications of simply taking a picture and posting it on the Internet. Potentially people can extract a good amount of information about you.

The tool that does this is exif tool.

The bottom line was be careful of what you post, and turn off geo tags if your camera provides that if you care about your privacy. This talk was well done and a lot of fun!


WiFi Security - this talk was given by Mike Kershaw and Brad Haines

The management frames in 802.11 are not encrypted, offering no protection at the network level. For example the beacon frames, that are broadcasted by a wireless access point.

You can sniff a wireless network when you put your wireless adapter into monitor mode or rfmon mode, assuming your driver and wireless card does support that.

A good model for security on a wireless network would be WPA Enterprise, as AES encryption as of yet is unbroken, and TKIP is showing flaws, and going away in favor of CCMP.

Have a look also at airpwn, evilgrade, airbase, and karmetasploit tools. The Rsnake VPN paper was also suggested as a good read, as that outlines cache control.


The Keynote speech was given by Dan Kaminsky

Securing String Interpolation

This idea is since developing code is a challenging process that leads to cross site scripting, cross site request forgery, SQL injection, and so forth, why not just make a unified way of making a boundary between data and code. Essentially he was suggesting to use his techniques using base64 encoding and decoding to maintain that boundary, you can find more here: http://www.recursion.com/interpolique.html

One of the ideas he has is that the application should fail close versus failing open, that way if the application is running, you know you're doing it securely, if it fails, you know you're not.

This was a great idea to at least put forward, as basically he was coming from the aspect of stop yelling at your developers to do it the way you want, and come up with a solution that will make it easier for the developer to develop secure code.

Great Hacks at the Olympics - this talk was given by Colin Keigher

This talk focused on the fact that the last Olympics spent $1 billion on security, yet the author and noticed that there were almost no security issues, other then a broken window on a storefront. He also noted it was easy to pose as a cleaning person, or a network reporter and the pass that allows you to gain access to the Olympics seems to be very easy to make (the actual barcode and actual pass shown in HDTV).


SHODAN for Penetration Testers - this talk was given by Michael Schearer

http://www.shodanhq.com/ was touted as a new tool for the penetration tester. For those who haven’t seen it basically this tool is indexing not the content of a page but the HTTP headers and errors of each page. This can make for some interesting querying to say the least!

Easy hacks on apartment phone systems - this talk was given by Davi Ottenheimer

In this talk of the author had found in his research some of those keycode entry systems at apartments unfortunately have been installed in the default mode. This means the password is likely the default, the admin mode is probably enabled remotely, and the open door sequence is easily gotten from the manufacturers website. So knowing the make and model of the security system, coupled with a default system makes for an easy entrance into an apartment, at times. The author had done some work and shared some of the details of getting into an apartment system, that are released in the wild.

This was a very interesting talk and one that needs further investigation if you live in an apartment.

MonkeySphere - this talk was given by Daniel Kahn Gillmor

Monkey Sphere is an opensource project whose goal is "to extend OpenPGP's web of trust to new areas of the Internet to help us securely identify servers we connect to, as well as each other while we work online" per the website http://web.monkeysphere.info/

What I found interesting was that it could bring PKI into OpenSsh, in a real way. No longer will you need to have an out of and phone call with the administrator confirming the key fingerprint of the remote hosts key. Sweet!

Risk Analysis - this talk was given by Nick Leghorn

In this talk the author was trying to suggest a way to do a risk analysis and boil things down into a way that the other party could really grasp. The key points that I heard was:

-That is very important to show a pattern in your chart, instead of simply "presenting data".
-Raw data is great if you have it, otherwise try to produce that data yourself, whether that's doing packet dumps, reading log files, etc. In the absence of any real data ask some experts for their opinion.
-When you rate a threat on a scale, it is more powerful to use even numbers that odd numbers.

Finally the six questions of risk, where you can find all here:

http://blog.nickleghorn.com/?p=583

Defending networks from malware using Nepenthes - this talk was given my Marco Figaro

In this talk of the author showed how to use the basics of the Nepenthes software - http://nepenthes.carnivore.it, which is open source software used to generate signatures from malware. "It acts passively by emulating known vulnerabilities and downloading malware trying to exploit these vulnerabilities." per the site. From there you could submit to your antivirus vendor, or your IDS vendor, etc.

The author is currently working on a very interesting security project called http://shaolintools.com/

on to The Next Hope Part 2 - Saturday and Sunday Notes

Medusa - Cracking Passwords

Medusa is one of many brute force password crackers on the Internet, and in my opinion one of the best.

I was able to quickly download, compile and install it quite easily on Ubuntu 10.04:

wget http://www.foofus.net/jmk/tools/medusa-2.0.tar.gz
tar zxvf medusa-2.0.tar.gz
cd medusa-2.0
./configure
make
make install

That's about all it should really take (in a perfect world) but Medusa delivered on that front.

Most pen-testers/sys admins/curious hackers are probably familiar with THC-Hydra which is also "A very fast network logon cracker which support many different services" per the author. It is mentioned many times in Network Security Assessment: Know Your Network, a great book by Chris Mcnab, however Medusa is not mentioned at all, mostly likely due simply to the author's preference.

Hydra is great in many regards, but medusa was very stable in my usage and had a syntax I preferred over THC-Hydra, and had a nice man page installed on Ubunutu as well. It may be help to view the Feature Comparison if you're making a decision for one versus the other.

For example it's easy to see what modules you can use with -d switch:

Using medusa was a breeze.

For test example I set my root MySQL user's password to "wicked" (as an homage to my Boston readers) and did 2 things:

1) Downloaded a wordlist to use as my password input file.

2) Used this syntax to brute force guess the password:

medusa -h 127.0.0.1 -u root -P /path/to/the-chosen-wordlist-from-above.txt -M mysql -e ns

The -e ns tells medusa to use some other options: a) check for No Password [n] and b) that the Password is the same as the Username [s] (just like THC-Hydra). The rest should make sense on their own.

A few minutes later I had an answer from Medusa:

You can see that Medusa correctly guessed the password in the screen shot.

Medusa's success (and other cracking tools like it) will be heavily dependant on the word lists used, so make sure you've got a good one.

Finally, the author makes a request on the site: "If you find Medusa useful and want to give something back, please submit new modules, code improvements or just buy any of the Foofus.net goons a beer at the next DefCon."

Absolutely Joe, what type of beer would you like?

Linux and the LinkSys WRT54G - Versions 5+

I had been meaning to install openWRT on my wireless router for some time. The router itself is about four years old, and while it serves the needs of my LAN well, it had some stability issues in that I needed to power it off every so often which was getting a little annoying.

I looked over the supported hardware list and I decided on a LinkSys WRT54G. I noticed that there were several different models and several different versions supported. How great is that? I had some extra credit within PayPal so I stopped over at eBay and purchased one that day.

After receiving the router I went through the installation docs on the openWRT website, and per the instructions I determined the version of the router matching up the serial number.

It turns out I bought a router that was a version 5 model. Per the website for version 5: "That version has switched to a proprietary non-Linux OS VxWorks. It has less flash (2 MB) and less RAM (8 MB). These versions are NOT supported."

Hmm, at least I have a nice router I thought. So as I was looking for a solution to this problem I happened upon another alternative called dd-wrt, which "...is a project started by Jeremy Collake (aka db90h) to flash a Vxworks based WRT54G/GS v5-v6 with third party linux firmware without the use of JTAG or serial cables. After considerable research and time, this has been accomplished!"

Beautiful!

The link, if followed exactly, which the author reminds you repeatedly for good reason, worked perfectly.

NOTE: Any reference to the Management Mode screen will look like this:

In step 16 the directions say refresh your browser window. You can see in this screen shot the results of what happens after step 13 where you hit upgrade:

You can just connect directly back to the IP address, without actually "refreshing" if using Firefox 3.6. NOTE: For some reason Firefox didn't like to refresh it's page during or after installation for any operation (Chrome worked fine).

If you have followed all the directions you finally get to a screen that looks similar to the following:

If you were to turn on telnet or SSH on one of the internal ports of the router (I'd strongly suggest using only as a SSH for security concerns) you can get a shell as follows:

It's a pretty restricted shell, of course to save RAM, but you can get to the inner workings of the router quite easily. Also since there is no binary for the "ls" command   I needed to use the syntax of "echo *"  to determine the actual directories and then cd into them to check them out. I printed out the details of meminfo, which told me out of just about 6 MB of RAM, 5.4 or so are used. That's pretty tight code to run a router,  DHCP server, DNS server and some other assorted services, all thanks to the open source movement!

Wire shark can decrypt SSL traffic, how?

Wire shark can decrypt SSL traffic, as documented here on their wiki:

http://wiki.wireshark.org/SSL

It mentions "..This only works for RSA key exchange if the RSA keys can be provided."

That's fine. But why?

The short answer is that if you were to use a certificate signed with a DSA signature, generally speaking, the SSL session will also use Diffie Hellman ephemeral mode for key exchange, (which incidently will grant you perfect forward secrecy), and therefore the private key of the certificate won't help you to decrypt traffic.

That is fair enough but not really a satisfying technical answer.

Here we'll talk about specifically why this is true.

In order to do so, first we will investigate why specifically we are able to eventually decrypt SSL connections when using an RSA key exchange.

To do so first let's review what happens in SSL secure communications between a Web server and a web browser.

During the initial handshake phase of SSL, the client issues a ClientHello record, and within this initial record (among other things) is a random integer presented to the server for use later on:



The server responds with a ServerHello and also sends to the client a random integer, also for use later on.



The Web Server also sends its SSL certificate in a Certificate record, and within this certificate is contained the public key of the Web server.

After the client has has verified the signature of the Certificate Authority within the SSL certificate, one of the steps it needs to perform is to generate something called the pre-master secret, which is a random integer that will also be used later on to derive the secret encryption key(s).

Specifically the client encrypts this pre-master secret using the RSA public key of the Web server. The Web server takes this value and decrypts the pre-master secret using its corresponding private key.

At this point the client and the server both know three values:
The client random value, the server random value and the client's generated pre-master secret.

The first two are known publicly and have not been transmitted in encrypted format. The only piece of information at this point that has been transmitted encrypted is the pre-master secret.

At this point both client and server take the pre-master secret, client random, and server random, and use them to run through a key derivation function, first to derive a master secret for the session, and then once again to derive the encryption keys, mac keys and other values that they may need.

The encryption key that we just derived is the key used for bulk data encryption. So as you can see this is not the private key that we use with Wireshark.

So if you have been capturing an SSL session with a tool like Wireshark or tcpdump, at key exchange time, it will be able to recover the initial client random and server random values, just like anyone who was listening to the network at that time.

The additional detail that Wireshark provides the user to input is the RSA private key of the Web server. Recall that this private key is the counterpart of the public-key (that was used to encrypt the pre-master secret by the client).

So now Wireshark has enough information to derive the master secret, and the other keys for the session, including the bulk encryption key(s), since it can decrypt the pre-master secret using the RSA private key. Thus we are now able to decrypt SSL traffic that has been encrypted when using an RSA key exchange.

If we talk now about a DSA based certificate, we need to remember that DSA technology is used for digital signature and verification, but not encryption, or key exchange.

We won't be able to encrypt the pre-master secret with a DSA public key in a key exchange like we did with the RSA key above, because again it can only be used for signatures and verifications.

In SSL, DSA technologies are generally coupled with Diffie-Hellman for key exchange, the full details you can read about in RFC 2631 or read a lighter version.

On a very, very, high abstract level, each party generates a Diffie-Hellman public and private key, and then exchanges its public key with the other side, and then uses its own private key, the other party's public-key and some other integers and numbers to eventually derive a shared secret value, that both parties know about.

Suffice it to say once the Diffie-Hellman key exchange has been performed each side is aware of a secret. This secret is the pre-master secret as we saw above. Both client and server go ahead and derive both the master secret and the eventual encryption keys for the connection.

So now what does Wireshark have to use if it was listening to that traffic? It doesn't have enough information to derive the pre-master secret. It doesn't know about the secret keys of either party, as those are never sent across the network, only the public keys, and other Diffie-Hellman parameters have been sent across the wire. So again, it can't derive the pre-master secret and ultimately derive the encryption key(s).

Also, those private keys are considered ephemeral, that is they are not stored anywhere, so after the key exchange and the session is over they will likely (hopefully) be destroyed never to be used again, and, in this case you'll gain Perfect Forward Secrecy.

Keep in mind now that even if you had the DSA private key of the Web server, Wireshark still could not decrypt this traffic.

Although it was used in signing the Diffie-Hellman parameters that have been sent to the other side, that private key doesn't factor in the computation of the Diffie- Hellman key exchange at all.

A great reference for anyone interested in learning more about SSL is Eric Rescorla's book, SSL and TLS: Designing and Building Secure Systems. I highly recommend it as it is an extremely detailed, complete view of SSL.

Also, check out the RFCs for:

TLS
http://www.ietf.org/rfc/rfc2246.txt

Diffie-Hellman Key Agreement Method
http://www.ietf.org/rfc/rfc2631.txt