Category Archives: Uncategorized

ProfiShark 1G – a 1 Gigabit network tap from ProfiTap

I’ve been fortunate enough to be allowed the purchase of a couple of network taps.
I was in the market for something portable to pick up traffic with my laptop wherever I would be. The relationship between price and functionality lead me to choose the ProfiShark 1G from ProfiTap.
I have had a few questions regarding settings (I’ll try to clear up those in this post) and their head of R&D was more than willing to answer my questions – appreciated Laurent! :-)

A few words about the ProfiShark 1G tap:

  • Fairly inexpensive (mind you no hardware like this is cheap!)
  • Uses USB3.0 to capture traffic – lets you have full use of your computer’s NIC while capturing.
  • Hardware timestamps accurate to 8ns
  • Hardware aggregating – meaning it will give you the full bandwidth of connected devices. Max 1Gbps in each direction at the same time will give you 2Gbps of data – no problem for the USB3.0 interface (has a maximum bandwidth of 5Gbps)
  • No need for external power – it is provided through USB3.0
    (you can however buy an external power supply if you need one)
  • Works 100% in pass-through mode when power fails.
    When power fails the link will go down for a period from 30ms up to 2 seconds (the latter if the link needs to be renegotiated)
  • Small size/light weight: 69mmX124mmX 24mm (2.72″X4.88″X0.94″)
  • Automatically sets speed at 10/100/1G according to connected devices’s capabilities

 

Why use a TAP as opposed to a regular NIC?

  • A TAP enables capture off a NIC as it is “booting” – that means you get absolutely everything that goes to/from that network interface card from the very start. That would no be possible capturing off a local NIC because the operating system will need to see the NIC as active before you can capture traffic off it with Wireshark.
  • A TAP will capture faulty frames (bad CRC frames are never picked up when you capture from the NIC)
  • TCP Offloading means the NIC chops up a large packet and sends it across the wire in severalt frames of appropriate size.
    Capturing traffic off the local NIC will wrongly show you this one large packet as one huge frame (a huge frame could be a Jumbo Frame, but is more likely the result of a NIC using TCP Offloading).
    Using a tap you will see the actual pieces/frames that cross the wire after the NIC chopped up the original packet.

Gotchas:

  • Note that the 8ns timestamp can throw you off – frames are stamped as they arrive on the wire and a large frame going in one direction will spend an equal amount of time passing through the TAP as several small packets going in the reverse direction.
    It can sometimes be mind boggling to make sense of timestamps and the order frames are listed in Wireshark :-)

 

Let’s have a look at the tap itself:

Figure 1: ProfiShark 1G tap
ProfiShark_tap
I have instructions taped onto the body for quick reference.

To the left are the cables from the client/server (green/gray) that the tap will listen to and to the right is the USB cable going to my monitoring computer (which has ProfiShark Manager installed).

The difference between Live and Direct Capture modes:
Live Capture mode:
Packets are captured the same as with any other NIC, and they are passed from the tap to the capture driver of the OS before capturing software (I use Wireshark) reads it.
Note: You can choose wether or not to use 8ns hardware timestamping. Refer to the part below about timestamping to understand how this affects the way frame timestamps are displayed in Wireshark.
Direct Capture mode:
The tap dumps packets straight to disk.
There is no need for third-party packet capture software.
This mode facilitates capture of small size frames at wire speed.
Note: Packets are always stamped with the 8ns hardware timestamp of the tap.
Refer to the part below about timestamping to understand how this affects the way frame timestamps are displayed in Wireshark.

Installation of the tap is a 2-stage thing
First install the neccecary software to make the tap show up as a network adapter/NIC in Wireshark.
To do this you run the Profishark_1.3.26.exe file found on the accompanying USB stick (or download from www.profishark.com).

Secondly you need to install the ProfiShark dissector to be able to read 8ns hardware timestamps in Live capture mode.
To install the ProfiTap dissector, you must copy the correct version of the profishark.dll to ‘C:/Program Files/Wireshark/plugins/[wireshark_version]/’
32-bit Windows -> x86 version dll
64-bit Windows -> x64 version dll

8ns hardware timestamps
Without this dissector (or if it is disabled) in Wireshark you will have timestamps flying all over the place when looking at traces taken with hardware timestamping in Live capture mode!
It is extremely important that you enable/disable the dissector as you work with traces that have/have not hardware timestamps!
Use the following table to see when to enable and when to disable the ProfiShark 1G dissector in Wireshark:
ProfiShark-dissector-matrix.
Again; failure to enable/disable the dissector will result in erroneous timestamps on frames in Wireshark!
You find the dissector in Wireshark (v.2.2.2) under:
Edit – Preferences – Protocols – ProfiShark

A word about the “Keep CRC32” setting in ProfiShark Manager:
The tap sees the 4 byte frame check sequence (FCS) or also called Cyclic Redundancy Check (CRC) that makes up the tail end of the frame as it reaches the tap from the wire. When you capture from a local NIC or use Live Capture mode with ProfiShark 1G, this FCS/CRC will already have been stripped off by the NIC/TAP – meaning all frames seen in captures originally were 4 bytes longer when they were traversing the wire.
When you use ProfiShark 1G in Direct Capture mode and leave the “Keep CRC32” unchecked, all frames will be passed on without the FCS/CRC. The trace files will contain both the wire size and captured size of each frame.
There will always be a 4 byte gap between these two sizes, and Wireshark will report this as [Packet size limited during capture] for some protocols.
When you use the TAP for Live capture, it seems the setting has no influence – the TAP reports captured fram size and seems to have no knowledge of the wire frame size.
Conslusion:
I always leave “Keep CRC32” checked to avoid frame size mismatches between wire size and captured size.

 

Summary:
A very nice size tap that does what it is supposed to.
The documentation leaves a lot to be desired, but hopefully this post will get you up to speed a lot faster than what I was :-)

Do get in touch if you have questions or comments!

 

 

Decrypting SSL traffic with Wireshark

There are primarily 2 ways of decrypting traffic with Wireshark:

  1. Logging client side SSL Session Keys 
  2. Using the private key of the certificate presented by the server side of communications

The first has the advantage of being readily accessible, but it can only be used to look at traffic generated at your capturing client and with software that will write its session keys to the environment variable ‘SSLKEYLOGFILE’
Only RSA keys are supported, so you will need to turn off support for DiffieHellman suites on the browser (use Firefox or Chrome – Internet Explorer is not supported).

The latter has the advantage of being able to decrypt any kind of traffic (as long as Wireshark has a dissector for it) – the downside is you need access to the server side private key (oops…. not always easy)

1: Let’s look at logging SSL Session Keys first:

You need to create the environment variable ‘SSLKEYLOGFILE’:

Windows:
Control Panel -> System -> Advanced System Settings -> Environment Variables -> Add ‘SSLKEYLOGFILE’ and point to a file to store the session keys (sslkeylog.log). Avoid spaces in the file path!

Mac/Linux:
Run the following command:
$ export SSLKEYLOGFILE=~/path/to/sslkeylog.log
Add it to your ~/.bashrc or ~/.MacOSX/environment (Linux or Mac)
to enable session key logging every time you log on to your system.

Wireshark:
After tracing some https traffic just point the Pre-Master-Secret log filename under preferences of the SSL protocol to you sslkeylog.log
That’s it – Wireshark should now show you decrypted traffic!

 

2: Decrypting traffic using
the server side certificate private key:

Remember: this requires that you have access to the private key of the certificate used to encrypt the traffic. This key should under no circumstances get into the wrong hands, and it is therefore imperative that you handle this method with care!
It is also important to remember that SSL decryption will only work on RSA keys – DiffieHellman suites are NOT supported (neither are any ephemeral versions of RSA).This is due to the very nature of DH being ‘forward secret‘.

Prerequisites:
  • Wireshark installation needs to be compiled with GnuTLS (not openSSL or bsafe). On Windows systems this will not be an issue, as Wireshark versions downloaded today will have GnuTLS-support built-in. Look for GnuTLS with Gcrypt in  “About Wireshark”.
  • only RSA keys are supported (not Diffie-Hellman).
    RSA Ephemeral Suites are not supported either.
    Most likely this will be a deal breaker as most servers today will choose DH and/or Ephemeral suites. To get around this issue you will need to reconfigure the server to prefer TLS_RSA suites:
    https://www.nartac.com/Products/IISCrypto/Download
    Look at ‘Client Hello’ what Ciphers the client want and move the first RSA cipher in the list to the top of the server’s list of available ciphers – this is achieved using IISCrypto.
    If you have access to the certificate private key I am assuming you have access to reorder ciphers as well.
  • Server side private key needs to be presented to Wireshark as a base64 encoded .pem file without a password.
    (Prior versions of Wireshark also supported the use of password protected PKCS#12-certificates, but this seems to have been removed in the later 2.x.x versions)
    Also – the Public Key must not be part of the .pem key file.
  • Important! The trace file must contain the initial SSL handshake – if the handshake was not captured in the trace, it will be impossible for Wireshark to decrypt the data within the SSL stream.
    NOTE: this means that SSL Fast Reconnect/SSL Resumption will ruin your chances if the client reuses a previously negotiated ‘Session ID’ – look for this in the Client Hello packet. If this packet contains a Session ID, the client is trying to use Fast Reconnect. If the server responds with a ‘Session ID=0’ that means the server will not do SSL Fast Reconnect. If it answsers with the suggested client ‘Session ID’ – you are victim of SSL Fast Reconnect/SSL Resumption.

Extracting the private key to use for decryption:

Export the certificate w/private key from the server in question (if private key is unexportable – see the part about using MimiKatz below)
The certificate should be in .PFX format and choose a password to go along with the export (PS! Do NOT delete the private key after successful export!)
This will give you a .pfx file that you can name something like: C:\certs\server01_cert_w_pkey.pfx

You need OpenSSL installed on your local computer. See https://sourceforge.net/projects/openssl/

Copy this .pfx file to your local computer and run OpenSSL against it:
C:\OpenSSL-Win64\bin\openssl.exe pkcs12 -nodes -in C:\certs\server01_cert_w_pkey.pfx -out c:\certs\server01_key.pem -nocerts -nodes
This will give you the following file: C:\certs\server01_key.pem

Now remove the password from this .pem file:
C:\OpenSSL-Win64\bin\openssl.exe rsa -in C:\certs\server01_key.pem -out c:\certs\server01_keyclear.pem 

This “server01_keyclear.pem” is the file that Wireshark will use for decrypting traffic that has been encrypted using the certificate you exported to begin with.

Using MimiKatz to get private key:

If the private key was marked as “Not exportable” when creating the initial CSR for the certificate you will have to use MimiKatz to extract it.
MimiKatz (http://blog.gentilkiwi.com/mimikatz)  is recognized as malware by most virus protection software, so beware! You will need to “white list” the program to be able to run it.
The following Powershell (run as Admin) commands are used with Mimikatz.exe to extract all certificates + private keys from the local computer store:
crypto::capi
crypto::certificates/systemstore=CERT_SYSTEM_STORE_LOCAL_MACHINE /export
This will create 2 files per certificate:  .der & .pfx
Take the .pfx file and continue above with OpenSSL (the password on the .pfx file is ‘mimikatz’) to make the .pem file for Wireshark.

 

 

Info about SSL Session Key logging has been leeched from this link:
https://jimshaver.net/2015/02/11/decrypting-tls-browser-traffic-with-wireshark-the-easy-way/

Skjalg
20160825

Packet tracing with iPhone

In order to troubleshoot ‘eduroam’ connectivity, I needed to capture traffic off an iPhone to see what was actually going on.

This is what I had to do to make this possible:

  • Jailbreak an iPhone (yes, it needs to be jailbroken and have access to the Cydia application store)
  • Install ‘tcpdump’ and ‘MobileTerminal‘ from Cydia
  • If you also want to transfer the .pcap-files from the iPhone via a USB cable to a (Windows) PC you also need to install ‘Apple File Conduit “2” ‘ on the iPhone.
    On the PC you will need iTunes and iExplorer (https://www.macroplant.com/iexplorer/)
  • open ‘MobileTerminal’ on the iPhone and enter ‘Root’ mode:
    type in ‘su’ and use the default password of ‘alpine’
  • (then type in passwd root and change the password to something else)
  • next start up tcpdump and start capturing traffic:
    ‘tcpdump -i en0 -w capturefil.pcap -s 0’
    -i en0 tells to trace off WLAN card
    (use -D to list available interfaces)
    -w specifies the file to write to
    -s is to make sure packets are saved in their entire length
  • to re run the last command type ‘!-1’ – that will save you some work typing long commands over and over again.
  • to copy/move the resulting .pcap-file to a PC, connect the iPhone to the PC via a USB cable and use iExplorer to browse to ‘root/var/mobile’ where the file will reside by default.

My interfaces were as follows:
1: pdp_ip0  (GSM-network)
2: en0           (WLAN)
3: lo0            (local loopback)

More information on available options for ‘tcpdump’ can be found here: www.tcpdump.org

Capturing traffic without installing anything!

Capturing traffic without installing any software:

  • By using the following method you will be able to sniff all traffic (including traffic dropped by the Windows Firewall) to/from a Windows host without ever installing any software. The packet capture driver is embedded in the .exe and runs without being installed.
  • Download microOLAP’s tcpdump.exe from http://www.microolap.com/products/network/tcpdump/
    Remeber that this version of tcpdump is tailored to Windows and requires a license!
  • tcpdump.exe MUST be run in a DOS promt & “Run as Administrator”
  • tcpdump.exe -D
    (displays available adapters to sniff packets from)
    This part can be a bit tricky – the names displayed are not always readily understandable. My tip is to run tcpdump.exe without any arguments on all interfaces in turn and see which have any traffic on them.
  • tcpdump.exe -i n
    (captures all traffic on interface n)
  • tcpdump.exe -i n port x
    (captures all traffic to/from interface n that is on port x)
  • tcpdump.exe -i n not host w.x.y.z and port x
    (captures all traffic to/from interface n on port x, except from that to/from host w.x.y.z)
  • tcpdump.exe -i n dst host w.x.y.z1 and not src host w.x.y.z2 and dst port 80
    (captures all traffic on interface n to w.x.y.z1 on port 80, except from that from host w.x.y.z2)
  • tcpdump.exe -i 2 -c 10 -v (dst host w.x.y.z1 and not src host w.x.y.z2) and dst portrange 80-90
    (the first 10 records of traffic on interface 2 that goes to w.x.y.z1 on any port in the range between 80-90, except traffic from w.x.y.z2 – with added verbose output “-v”)
  • tcpdump.exe -i 2 -c 10 -w outfile.pcap (dst host w.x.y.z1 and not src host w.x.y.z2) and dst portrange 80-90
    (same as above but written to file outfile.pcap)
  • tcpdump.exe -i 2 -c 10000 -w outfile.pcap (dst host w.x.y.z1 and not src host w.x.y.z2) and (dst port 80 or dst port 8090)
    (same as above, but with individual ports specified)
  • tcpdump.exe -i 2 -c 10000 -w outfile.pcap ((dst host w.x.y.z1 and not src host w.x.y.z2) and (dst port 8040 or dst port 8043 or dst port 8050 or dst port 8053)) and “tcp[tcpflags] & (tcp-syn|tcp-ack) != 0”
    (Interface #2, Count = 10000, Write to file outfile.pcap in current directory, all SYN and ACK packets to w.x.y.z1 on ports 8040, 8043, 8050 or 8053 except those from w.x.y.z2
    PS! This filter will NOT give any SYN/ACKs sent back from the server to the client – only the initial SYN & SYN/ACK from clients + all other ACKs from clients)
  • tcpdump.exe -i 2 -c 10000 -w outfile.pcap ((dst host w.x.y.z1 and not src host w.x.y.z2) and (dst port 8040 or dst port 8043 or dst port 8050 or dst port 8053)) and “tcp[tcpflags] & tcp-syn != 0”
    (Interface #2, Count = 10000, Write to file outfile.pcap in current directory, all SYN and ACK packets to w.x.y.z1 on ports 8040, 8043, 8050 or 8053 except those from w.x.y.z2
    PS! This filter will NOT give any SYN/ACKs sent back from the server to the client – only the initial SYN from clients)
  •  .\tcpdump.exe -i 6 ‘ip[0] & 15 > 5’
    Shows all IP traffic on interface 6 looking in the 1st byte (0) with a value larger than 5 with a mask of 15 (0000 1111).
    In reality this filter will show you all IP traffic with headers larger than 20 bytes (5 x 32bit blocks of header data = 160bits -> 160bits/8 = 20 bytes)

 

Certificates – “quickie”

Here comes a “quick” overview of certificates – how they work and what they are used for (it grew on me as I was writing….)

 

What:

I’m sure you’ve heard of them and wondered what they really are and how they work – digital certificates.
You find them all over the digital world today – from digital signatures on small executables to the web pages of the world’s largest banks.
It is important that you know what they are, so that you can better employ them in your environment and also to protect yourself.

Certificates are small digital files typically used for:

  • validating an identity (server, user, service etc)
  • encrypting data (stored or in flight)
  • signing data

Certificates can be either private or official – meaning they have been signed by an internal private Certificate Authority (CA) or by an officially recognized CA that is known to be trusted.

Hashing, symmetric/asymmetric encryption and signatures

Hashing is the procedure of generating a unique, fixed size output from any input. It is meant to be a one way operation, but several hashing algorithms have been broken through the years.
If you input a certificates data into a hashing algorithm (i.e. MD5) the output will be unique. No matter how many times you run the same data through the hashing algoritm, the output will always be the same. However, if you change the input just the slightest, the output will change to something totally different. Also, it is imposssible to reverse a hash into the text that generated it. It is like “1+1+1+1+1+1=6” – but if you are given the “6” you don’t know what calculation “6” is the answer to.
To be able to hack a hash, you simply need to try all kinds of different inputs until one matches the output you want to spoof.
For that reason hashing algorithms are designed to be slow so that breaking them will be time consuming. It takes relatively long time to generate a hash from even the smallest amount of data, so that super computers will not be able to run through all possibilities and reveal the hash in a hearbeat.
Remember that spoofing a certain hash is not the challenge – the challenge is spoofing the hash while still making it look like the data being presented makes sense. In a certificate’s case it would still need to be humanly readable and make sense.

Examples: MD4, MD5, SHA-1, SHA-256

Symmetrical keys are simply keys that are the same – the same key that was used to encrypt can also be used to decrypt. This means anyone who gets hold of the key can read/alter the message without the final recipient knowing. A session key in https:// is an example of a symmetrical key.

This is why you must capture the initial SSL handshake to be able to decrypt SSL with Wireshark. That is where the session key is derived from the server’s private key, and so it is the only place where the server’s private key can be applied to reveal the session key that will allow you to peek inside the SSL traffic.

Examples: DES, 3DES, Blowfish, Twofish, AES (Rijndael)

Asymmetrical keys are what is used in PKI
(Public Key Infrastructure)

What is encrypted with a private key can only be decrypted with the corresponding public key, and vice versa. These keys are always produced in pairs.
They are most often generated locally on a system within it’s crypto system (in case the public key needs to be verified as belonging to it’s private partner, the public key + some other data is delivered to a CA for signing).
During SSL handshake the asymmetrical keypair is being used to generate a symmetrical key that is valid for the length of the session (also called session key). The certificate’s public/private key pair is NEVER used for encrypting the communications stream – it is simply used to negotiate a shorter/simpler session key. This is because it would be too labour intensive on the server’s side to encypt/decrypt with 2048/4096++ keys.

Examples: DH (Diffie Hellman), DSA (Digital Signature Algorithm) and RSA (most common – supports both encryption and signature).

 

PKI is the basis!

An asymmetrical key pair is the key to all.
One key, the private, should NEVER leave the local system (exeptions made for EFS (Encrypted File System) and such, where private key archival is used). Whatever has been encrypted with the private key, can be decrypted with the public key – and vice versa. As long as the private key is kept secret, the corresponding public key can be used to verify the origin of an encrypted message/data (requires that the certificate gets signed by a CA that the relying party trusts).

Common confusions in PKI:
  • Public key:
    A key used to decypt data encrypted with the corresponding private key.
  • Private key
    A key used to decypt data encrypted with the corresponding public key.
  • Certificate
    A signed version of the public key + some other data such as the entity’s name (CN=server1), DNS name (Subject Alternate name DNS=server1.example.com)
  • WYSIWYG (What You See Is What You Get) – No, most likely not.
    When you inspect a certificate in Windows, there will be a few fields with properties that are actually from the certificate file – whereas many fields/properties will be computed from the certificate file data.
    certfields01 certfields02
    First are the actual certificate fields, then the certificate extensions and finally computed fields.
  • Thumbprint
    The thumbprint is NOT part of the certificate – it is a hash that is being calculated on the certificate when it is read. If this hash is to be used for some kind of validation between communicating parties – it is vital they both compare a hash calculated using the same hashing algorithm.

Root CAs or Trust Anchors

Any certificate that should be trusted needs to chain up to a “trust anchor” – a certificate from a Root CA (official or internal to an organization – it doesn’t matter) that has been accepted by the user/computer/application as trustworthy. Such Root CA certificates live in certificate stores – the OS has one and so does other applications (i.e. Internet Explorer).

How:

To be able to validate an identity, we need to trust someone at some level. This “someone” in reality is whatever trusted authorities the operating system vendor has put in the operating system trusted store at point of release and through OS updates. Typically there will be some 10+ really large organizations specializing in validating identities (Certificate Authorities or CAs) already in the OS’s trusted store before you add your own (optional).
As the user of i.e Windows 7, you inherently trust all certificates issued by the CAs already in Windows 7’s trusted store. That means that if some web site presents a certificate issued by one of the CAs in the store, you automatically trust that certificate, and the web page will use https without any more adue. Had the certificate been issued by a smaller CA or even a private CA (you can set up your own internally), you would’ve been presented with the certificate and asked whether to trust it or not before continuing.
If you choose to trust a CA not already in your OS’s trusted store, you need to realize that ALL other certificates issued by that CA also will be trusted.
So what makes a CA trustworthy? Different CAs use different levels of background checking before issuing a certificate. There are also different levels of certificates (seen that green address bar that some certificates give your browser – that is a highly trustworthy certificate that the site paid lots of money for) that you can buy from the different vendors. All that being said, as long as the CA is trusted by the OS all certificate types from any vendor (be it Thawte or your own internal CA) are technically equal and valid.

OS/Application certificate stores

All operating systems have some sort of store where they keep a collection of certificates from CAs they trust. Some applications also keep their own store that they use for reference – Java on Linux being one example. This enables the Java application to trust sources that the OS shouldn’t necessarily trust.
A store typically contains “Trusted Root CAs”, “Trusted Intermediate CAs” and locally installed certificates (certificates that the local computer can present to clients accessing services on the computer). Locally installed certificates can also be certificates that this server gets presented from a communications partner – some applications require them to be installed locally for comparison.

Certificate chaining/Certification Path Processing

All certificates have what is called a certificate chain – that is a “route” up to the Root CA that is responsible for the issuance of that certificate. A server certificate can point to an Intermediate CA that issued it’s certificate. That Intermediate CA can the have a certificate that points to a new Intermediate CA or a Root CA.
A root CA will always be it’s own issuer, there is no one above (that is the very definition of a root certificate).
To be able to verify a certificate’s chain, you either need all certificates in the chain in the local computer’s certificate store – or at least the Root CA certificate. Intermediate certificates can be validated “on the fly” – that is the local computer can go online and check the validity of the certificate’s issuing CA, which then again checks the validity of the CA that issued that certificate and so on.
But when the check finally reaches a certificate that was issued by itself (the very definition of a root certificate) then that Root CA’s certificate need to be in the local computer’s “Trusted Root CA” store. To make this possible it is neccecary that all CA certificates be downloadable for the local computer, or else it will not be possible to perform the check (they are typically placed on highly accessible web servers).
If some certificate is revoked (the issuer replaced it due to technical reasons or it has been c ompromised) that certificate is placed in the CA’s CRL (Certificate Revocation List). This file needs to always be available and the CRL location is always part of the properties of a certificate.

 

How certificate validation is performed

  1. Chain building
  2. Chain validation

When a certificate has been presented to the local computer (i.e by a web site), the local computer pays careful attention to certain fields within the certificate:

  • Certificate validity – the certificate needs to be within it’s validity period. If not it is discarded as not trustworthy.
  • Subject & Issuer – if these are the same it knows this is a root CA’s certificate.
  • Subject Key Identifier – used in chain building
  • Authority Key Identifier – used in chain building
  • AIA (Authority Information Access) – this is where information about the certificate’s issuer can be found.
  • CRL (Certificate Revokation List) – this is where the CA that issued this certificate places it’s list of certificates that should no longer be trusted.
  • Basic Constraints – End Entity must be “NO” for a CA.
  • Signature hash Algorithm – used to verify the certificate origin.
  • Thumbprint – this is the certificate’s unique identifier. The CA that issued the certificate will keep a list of thumbprints for all the certificates it has issued.

Different OSs perform their certificate validation checks at different degrees of thoroughness. Ideally this is what should happen:

  1. Certificate path is built from leaf to root
  2. Certificate validation is done from root to leaf
  3. Does Subject = Issuer? (proving this is a Root CA).
    Is this Root CA in the trusted store?
    No -> prompt user to accept new Root CA into trusted store, or abort check with error.
    Yes – Move on
  4. Certificate within it’s validity period? Yes -> move on
  5. Certificate valid as CA certificate? (CA=true) Yes -> move on
  6. Validate with Issuer/AIA that it actually issued this certificate.
    This is validated by running the certificate’s signature algorithm on certain parts of the certificate. Then the certificate’s signature is decoded with the Signature Hash algorithm using the issuing CA’s public key as input. If the 2 are the same -> Certificate is OK.
    In the case of Root CAs the Issuer/AIA will be the Root CA itself.
  7. CRL available? Yes -> move on
  8. Check CRL to see if certificate has been revoked ? Not revoked
    -> move on
  9. Now look at the next CA’s certificate and perform steps 4 through 8
  10. Repeat for all CAs
  11. Finally validate the leaf certificate.

Standalone vs Enterprise (AD integrated) CAs

In short commercial CAs are typically standalone and CAs internal to organizations running MS Active Directory are typically Enterprise (Intermediate ones – private root CAs are often Standalone so that they can be turned off for security reasons ).

Standalone:
  1. CA offers a few options to choose from when it comes to validity periods and how deeply the certificate is validated. Domain Validated, Organization Validation and Extended Validation all give the user a different degree of trust in the certificate.
    EV certificates are the ones that turn IE’s address bar green – typically used by banks etc.
    Depending on which validation is used the supplicant can have more/less attributes of the certificate filled in.
  2. Supplicant provides all other information that goes into the certificate themselves (as opposed to templates used by Enterprise CAs)
  3. Standalone CAs never know the private keys of their supplicants
  4. Standalone CAs issue certificates on a per CA administrator approval. That means it is the CA admin’s job to validate if a certain request from a supplicant should be met and a certificate issued. This makes the Standalone CA a very time consuming setup as opposed to the Enterprise CA.
Enterprise:
  1. Used by organizations that are not official CAs, hence the logic behind DV, OV and EV makes no sense.
  2. Organizations will install the certificate of their own Root CA in the trusted root store of all their computers (servers and workstations) and thereby make it a trusted one.
    This is normally done through imaging or Group Policies.
  3. Enterprise CAs support the use of templates, which makes the CA able to decide on many properties on behalf of the supplicant.
    The supplicant typically needs to specify its name and what certificate template it wants to use (templates are typically named to identify their use – WebServer5yrs, UserCertLync, EFS etc). Within each of these templates are the settings needed to make the certificate useable with the application that it is intented to be used with.
  4. Being AD integrated, an Enterprise CA can extract information from AD and automatically sign and issue certificates that AD entities apply for. This makes an Enterprise CA highly efficient in issuing certificates.
  5. An Enterprise CA can be setup to archive private keys. Now, that might sound strange right? Remember this can only be done on certificates that the CA automatically issues based on information it finds in AD && that has been configured by the CA administrator to be able to be archived. Archival is an organizational decision – should it be allowed, and if so, on what types of certificates? Typically it is enabled on EFS certificates (Encrypting File System). This enables the CA administrator to reissue the public/private key to a user should the keypair be lost.
    This happens if the user’s computer is reimaged or could potentially be the result of a crashed computer. Had the key not been archived and consequently retrieved, the user would never be able to access his/her files ever again.
    This is the only time I know of when the CA would have a copy of the private key of a certificate (apart from the private keys to it’s own certificates of course).

Cross certification

Two different organizations with totally different PKI solutions in place can choose to trust one another’s CAs (be it root or at a lower level). When set up, certificates from OrgA are trusted in OrgB and vice versa.

Thoughts

  • Remember that all hashing algorithms WILL BE BROKEN sooner or later – it is only a matter of time.
    Data stored and protected by such will have little/no value in the future.
    Data communications today will be safe from eavesdroppers, but remember that large entities can pick up the data off the wire and save it for later days when it can be reverse engineered.
  • Cryptographic algorithms will also be subkect to breaking as years go by. Due to their nature of negotiating individual session keys, they will require slightly more data to “mine on” to be broken – nevertheless they should be considered unsafe for future replay/reverse engineering.

 

Needs work:

  1. What exacly is being hashed for use as the basis for the signature hash?
  2. SSL  in Wireshark. If you use a Base64 .pem-file containing ONLY the private key, will Wireshark be able to decrypt any protocol within SSL, or only a select few? Do you specify “Data” or the name of the protocol?

HW to get you started…

Before you go out and buy some really expensive network taps, I suggest you look into buying one of these NetGear GS105 switches and play around with capturing traffic in a smaller scale:

The unit is “only” 500Mbps when used in mirroring mode and will not be as good as a dedicated tap, but will be more than enough for capturing lower bandwidth traffic for learning purposes. Mine has been ordered, and I can’t wait to use it for IPv6 Multicast traffic analysis :-)

 

PS! Remember to filter out all traffic to/from your network analyzer’s NIC. If not, you will be seing all the mirrored traffic you want to see + all traffic generated by the PC running Wireshark.

 

20160210 Update:
Got the device and set it up to mirror port #5 to port #2.
Works like a charm – the only thing you need to remember is that the destination port (in my case port #2) will still work as a switched port on its own. This means you will be able to surf the web on your mirrored/spanned port at the same time that packets are being copied over from the source port (port #5 in my case).
To only capture traffic to/from the device connected to your source port, use this capture filter in Wireshark:
ether host 01:02:ae:02:bf:ef ( the latter being the MAC address of the device connected to the source port)

Where do I capture traffic?

Where you capture is important:

  • Capturing locally on  a computer connected to a switch port will let you see all traffic to/from your computer only + any broadcast traffic that gets sent down from the switch.
  • Capturing off a hub (true layer 2 device) will give you all the traffic to/from all devices connected to that hub.
    Note that many devices marked as “hubs” actually are switches – see https://wiki.wireshark.org/HubReference for more information.
  • Capturing off a wireless network follow the same principles as capturing on a hub.
  • Capture off a spanned switch port to “eavesdrop” on all traffic to/from host/hosts connected to that port.
    Remember that you will need administrative access to the switch to setup a spanned port.
    A down side to this approach is that you risk loosing traffic due to the fact that the switch will prioritize it’s core functionality of switching traffic before copying traffic over to the spanned port.
  • Capture off a network tap. Taps are specialty devices designed for the sole purpose of letting you listen in on network traffic. There are aggregating and non-aggregating taps. The latter will only let you see traffic in 1 direction at a time, so to capture a stream of traffic you would need 2 taps. Aggregating taps let you see traffic in both directions at the same time, but this comes at a price – they are in general more expensive. Taps typically have built in memory to make sure traffic gets captured even during the most busy peaks of network traffic (a regular computer will typically realize packet loss during such peaks).

Is Wireshark the only tool available?

Whenever I need to look at network traffic to see what is actually going on, I use Wireshark.

There are other options however, but I prefer the “true” nature of Wireshark. What you see is what you get.
As Laura Chappell puts it: “Packets don’t lie!”

Tools like Microsoft’s Network Monitor might give a more insightful look at the total picture of what is going on, but it will not show what truly flies by over the network – it will show an excerpt of the network traffic mixed with all kinds of application/OS layer data.
Fine for those who want that, but I focus on the network layer
solely – believe me there is more than enough to look at there!