WirelessPhreak.com

travel, science, technology, and all other geeky things
Follow Me

Mutual authentication or two-way authentication refers to two parties authenticating each other at the same time. Below is an excerpt from the Wikipedia page, they did a nice job explaining what mutual authentication is.


By default the TLS protocol only proves the identity of the server to the client using X.509 certificate and the authentication of the client to the server is left to the application layer (for example, username and passwords.) TLS also offers client-to-server authentication using client-side X.509 authentication. As it requires provisioning of the certificates to the clients and involves less user-friendly experience, it's rarely used in end-user applications. But at a small scale or proof of concept this is completely reasonable.


Mutual TLS authentication (mTLS) is much more widespread in business-to-business (B2B) applications, where a limited number of programmatic and homogeneous clients are connecting to specific web services, the operational burden is limited, and security requirements are usually much higher as compared to consumer environments. The factor that impacts scaling of this design is not the technology, devices are built to handle millions of SSL transactions, but the policy and procedures around the certificate management and client on-boarding. 


In this example a client will be connecting to an Apache web server and authenticate using mutual TLS authentication.


First you must build the web server running SSL. You can find a lot of step by step articles online about how to build an Apache web server preferably on Linux. Also take a look at Lets Encrypt, it's a free SSL certificate issuer that is freaking awesome.


Once you have your web server up and running you will want your client to generate a certificate. This can be done using OpenSSL the de facto for everything SSL on the internet. There are some awesome guides on how to build out the mutual SSL authentication and the accompanying Apache config. The best one I found was on stefanocapitanio.com they do a great job of outlining each step that makes up the mutual TLS authentication. In this example I will Jump ahead to the certificate creation,


This will generate your private key and certificate. You will need to answer the following questions when prompted this makes up the attributes of your client certificate.

openssl req -newkey rsa:2048 -nodes -keyout key.pem -x509 -days 365 -out certificate.pem
Here is an example what it will look like.
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) []:US
State or Province Name (full name) []:State 
Locality Name (eg, city) []:City
Organization Name (eg, company) []:Anything
Organizational Unit Name (eg, section) []:Anything
Common Name (eg, fully qualified host name) []:Username
Email Address []:youremail

Next we will combine the Key and Certificate in PKCS#12 file:
openssl pkcs12 -inkey client-key.pem -in client-certificate.pem -export -out bundle-certificate.p12
This file will be the private key and certificate combined with a secure password. This is what you will install on your OS or browser (such as firefox) to encrypt your data and issue to the server as your identity.

Once you have generated and installed your client certificate you will want to send ONLY THE PUBLIC CERTIFICATE, in this case client-certificate.pem to the server admin. Your public certificate will be what is used to identify your machine when it attempts to connect tot he web server. Read up on the Apache man pages about he SSLVerifyClient options there is quit a but out there. This is a very basic config.

The server admin will place your certificate in their certificate store and configure Apache.
<VirtualHost *:443>
ServerName secure.example.com
DocumentRoot "/var/www/html"
 ServerAdmin [email protected] SSLEngine on SSLCertificateFile /home/sempla1/ssl/server-cert.pem SSLCertificateKeyFile /home/sempla1/ssl/private/server-key.pem SSLVerifyClient require SSLVerifyDepth 10 SSLCACertificateFile /home/sempla1/ssl/client-certificate.pem
</VirtualHost>

Once the server has been configured you can attempt to connect. Normally you will be prompted to provide your client certificate if it is working. This is apache asking for your public certificate to validate it is the same one that Apache was configured with. In firefox you can go into Preferences then Security and Privacy and tell the browser to automatically issue that certificate if you like.

That's it I had a good time playing with this I hope you do as well.





Defcon is Canceled!

The meme that never dies finally became a reality. I have attended Defcon for nearly 2 decades and every year I am excited to see friends but dread staying in Vegas. This year my dread turned into mourning. After Jeff's initial COVID post, the progression of the pandemic, and the physical conference cancellation, I feel Defcon is more important than ever.

Most con attendees identify Defcon as a way of life just not a conference. It is our responsibility to keep Defcon alive, share in the intellectual, the consciousness, and the bonds that make up Defcon. If this means meeting in smaller groups locally or hanging with friends online we can still make Defcon, Defcon...


**One Idea**
Perhaps, depending on the state of the pandemic locally, DC groups could throw classic Defcon parties. DJs, drinks, and attendees bring a Defcon badge from any year to be admitted. Of course, the badge idea could be a loose requirement since we wouldn't want to exclude anyone who hasn't been to Defcon. It might be a cool way to locally create that Defcon atmosphere.