Pardon the sites appearance. I am in the process of migrating hosting providers.
Pardon the sites appearance. I am in the process of migrating hosting providers.
I’ve recently posted two articles covering two different VPN connection methods. SSL Remote VPN and IPSec Remote VPN via Cisco ASA security applicance. In the article I promised I would go thru and do a deteail compare and contrast of them. So Let’s get start!!
As promised here is the follow up post I mentioned here regarding setting up an Cisco AnyConnect remote access. Luckly the process is very similar to a remote access IPSec tunnel in the previous article with a few exceptions. Lets work through the differences between Cisco AnyConnect and a standard remote access IPSec Client VPN.
|Comparison||SSL Remote VPN||IPSec Remote VPN|
|Cost||$$ per Connection, SSL certificate costs||Usually none, no SSL certificate costs|
|Capacity||Seats limited to licensing||Limited to Crypto Hardware|
|Performance||SSL with DTLS = Very Fast||IPsec without NAT-T = fast|
|Vulnerability||SSL vulnerabilties released frequently||IPSec requires pre-shared key|
|Requirements||SSL requires TCP 443, DTLS requires UDP 443||IPSec requires IP Protcol 50 (ESP) and UDP 500(IKEv1), NAT-T requires UDP 4500|
|Connection Considerations||SSL requires TCP 443 outbound for clients||IPSec requires both Layer 3 and Layer 4 protocols|
NOTE: The table here is a quick reference when comprising SSL remote VPN with IPSec remote VPN. There are many things to consider when choosing between the two. SSL VPN is newer than IPSec, however the answer on which is better is not so straight forward.
IPSec remote VPN utilizes a variety of protocols and ports to form a successful tunnel. If you remember from my article on IPSec and NAT-Traversal, port requirements are UDP 500 for IKEv1 exchange, IP Protocol 50 for ESP communication, and if negotiated UDP 4500 for NAT-T. Most of the time these ports and protocols will not be allowed access outbound to the Internet. For instance, many guest networks like hotels and conferences only allow web browsable ports, such as 80(HTTP) and 443(HTTPS) outbound. That is a lot of firewall exceptions to establish an IPSec remote VPN.
SSL remote VPN introduces many connection and scalability improvements, making remote VPN functionality easier for the end user. SSL remote VPN solves the IPSec issues of a opening ports to establish a VPN session. Remote users no longer connect differently depending on where they are nor do they need to know how they are connected to the Internet, no fancy ports need to be opened, no issues with NAT-Traversal, etc. SSL remote VPN uses a very common trusted port for communication TCP 443 (and UDP 443, more on that later). This port is 99% of the time open to communicate with the Internet web sites. Using a commonly allowed port eliminates the issues seen with IPSec when establishing a VPN.
The trade-off, SSL remote VPN communicates via SSL/TLS. As stated this requires TCP, which is a stateful transport protocol. The issue arises when you have a remote host operating an application that uses TCP as well, such as web browser or Remote Desktop Connection. The scenario is now TCP on top of TCP, resulting in heavy overhead. Imaging the following scenario, you have a SSL remote VPN host connected, they then open a RDP session to a server on your network. So far so good. Now what happens when either the RDP session or the SSL remote VPN session requires a re-transmission because of connectivity problems. TCP re-transmission storms. Both the VPN session and RDP session will require re-transmissions, generating heavy overhead. Now this is not to say that either session will not recover, cause they will unless the connection is completely severed, TCP will do its job. Datagram Transport Layer Security(DTLS) to the rescue!!!
DTLS is the savior and its what makes SSL client VPNs a very competitive remote access VPN technology. DTLS was designed to secure traffic similar to TLS, but without having to rely so heavily on the underlying TCP transport. TLS relies on TCP to guarantee delivery in the event of message fragmentation, message reordering, and message loss. So getting ride of any one of those TCP features will break the TLS crypto logic. DTLS solution to these issues is as follows:
Keep in mind that DTLS built-in functionality of these usually transport specific recovery mechanisms creates the need for additional RAM/memory on the server-side. Another cool fact is most of these “fixes” come from IPSec ESP technology! See RFC4347 for more information.
I have a few Debian servers that are behind a firewall and they don’t have direct access to the internet. “Protected Servers”. I occasionally have to update their packages via a web proxy in the DMZ. I know there a countless ways to do this, but I wanted a one-liner that i can use without having to modify the apt-get application or my hosts default proxy settings.
Hope this helps someone else, cheers!
http_proxy="http://172.16.0.5:3128" apt-get update
Hello! I posted an article a while back on how to use a web proxy to block unwanted content. While this is good and fun, we need an easy way to configure clients to use the proxy. For this article I will be over both PAC file deployments and WPAD deployments. We will use the example proxy server of 172.16.0.5:3128. Let’s go!
First I’ll list a few common ways clients are configured to use a Web Proxy:
Like many of you I tend to browse Imgur from time to time. I noticed a few times some folks were showing off their build of a Smart Mirror and I thought to myself that would make a great thejimmahknows post! So here we go!
I wanted to put together a quick tutorial for setting up a Cisco ASA – AnyConnect with SSL/TLS. I’ve done it a few times and I always have to re-lookup each step and the order in which to do it, so why not make a quick post about it to remember!
You will have to destroy or clear out the current trustpoint if it already exists. This must be done if you are going to re-generate the key, which is best practice when renewing a Certificate due to expiration or one that has been compromised.
asa01(conf)# no crypto ca trustpoint oldtrustpoint.trustpoint
Here we start with the generation of our key, using 2048 bits. the key name can be anything you want, but I like call it by the service I will be putting it on, for my case for this tutorial is accessthejimmahknowscom.key
asa01(conf)# crypto key generate rsa label accessthejimmahknowscom.key modulus 2048
First we need to set up a trustpoint object, with our locale properties, etc
asa01(conf)# crypto ca trustpoint newtrustpoint.trustpoint asa01(config-ca-trustpoint)# subject-name CN=access.thejimmahknows.com,O=thejimmahknows,C=US,St=Connecticut,L=Wethersfield asa01(config-ca-trustpoint)# keypair accessthejimmahknowscom.key asa01(config-ca-trustpoint)# fqdn access.thejimmahknows.com asa01(config-ca-trustpoint)# enrollment terminal asa01(config-ca-trustpoint)# exit
So a recent post I published talked about 1-Way vs 2-way SSL Authentication in some decent detail. We learned that 2-Way “Mutual” SSL Authentication can be used to enforce both parties attempting to communicate securely to provide authenticity. In other words, prove to each other that they are who they say they are. This can be very powerful from a security standpoint, but is it practical? The answer is, yes and no. The constraint comes from the aspect of administration (actually create certificates for each client) and manageability (keep accounting and maintaining actively lists of trusts) with the trade-off of proper authenticity. For example at first administering and managing 10 client certificates may be okay, but then imaging 100, or even a 1,000! So in this post I wanted to approach the idea of utilizing some tools we can use to offload some of this administration and management while maintaining Mutual Authentication with another entity. The idea revolves around one major assumption, users of a particular service (In this case a web-server) reside on a privately controlled and trusted network
My idea is if we have a group of clients residing on an internal privately addressed network, we can use either an F5 LTM or HAProxy to proxy our users’s connections destined for a service that is enforcing 2-Way SSL “Mutual” Authentication. The F5 LTM or HAProxy would perform the 2-Way SSL Mutual Authentication on behalf of each connecting user, eliminating the technical need to generate certificates for each client, while maintaining an element of mutual trust to the end service.
The basic idea is: (notice only our F5 LTM/HAproxy and the web-server perform 2-Way “Mutual” Authentication)
SSL Authentication is nothing more than proving the authenticity of one or both parties in the formation of an SSL “Secure” connection.
1-way “Standard” SSL Authentication is the most common, you use this every time you log into Facebook, your bank website, google, etc. The point of this type of authentication is for you (as the client) to verify the authenticity of the web site you are connecting to and form a secure channel of communication.
2-way “Mutual” SSL Authentication is less common than the traditional “one-way” SSL authentication we are a custom to when visiting secured websites. When we connect to our banking website or our favourite web e-mail site, we as the client are verifying the identify of the site we are requesting content from. This “one-way” authentication allows us as the client to connect with confidence that the web site we are receiving content from has been verified. this authenticity check is performed by our client browser with a little help from a third-party certificate authority.
Let’s first review a one-way SSL connection.
So as we can see from a traditional SSL handshake, the client is never verified as authentic. Now, in most situations this is fine, as most connect types of this nature only need to verify the server because that is where the content is coming from.
The difference: In a 2-way mutual authenticated SSL handshake, the server will ask the client to send its own certificate for verification. Just like the client asking for the server’s certificate in the 1-way SSL handshake above, the server will perform verification of the client certificate before continuing to the pre-master and master secret phase of the SSL handshake. If authenticity of the client cannot be verified the server closes the connection.
How is mutual trust obtained? Both the server and client must generate their own SSL certificate and keys, and both must be signed by the same Certificate Authority. This ensures that both the server and the client’s certificate are trusted. This allows authentication to remain asymmetrical, instead of symmetrical. For example, rather than have a shared password that 3 clients and the server use to encrypt and decrypt data. Each client and the server have their own certificates and keys that will be used for communication with the server. Asymmetrical authentication and encryption is better at enforcing authenticity because everyone has their own cert and key used to establish a secure connection with the server. Symmetrical authentication is faster at encrypting and decrypting but suffers from having every client use the same key.
What happens if a client key is compromised? In the symmetrical authentication scenario, mentioned previously, you would have a serious security issue on your hands. Each client would be at risk and the likely hood of eavesdropping would increase. An attacker only has to obtain one key to gain visibility into every connection. Asymmetrical on the other hand has a different way of handling this. Because each client has it’s own certificate and key pair, and the signing of each certificate is performed by a third-party Certificate Authority, one simply has to revoke the compromised client in the form of a CRL certificate(more on this later). Other client connections will not be compromised or have to be re-generated. The server verifying the client certificate will fail only for the revoked for the compromised client.
What happens if my Certificate Authority’s key is compromised? This is the worst case scenario that can happen in your PKI infrastructure.An attacker can impose and generate a new certificate authority certificate and start signing certificates that can be used to fake authenticity. In essence break the certificate authority’s trust. Keep in mind a Certificate Authority key cannot decrypt your connections.
So it finally happened. The Batteries in my APC SUA3000RM2U finally went bad. I’ve had them for over 5 years so I am happy with there life. I’ve had to replace UPS Battery Cartridges and Packs before when working as a Data Center consultant. It is usually a simple and straight forward task. I would RMA the Battery Cartridge or Pack, if it’s under warranty, and then the manufacturer would send me back a new Battery Cartridge or Pack already filled with new batteries. Hot swap it with the old one and you are done.
However, this time it was my home unit and I don’t have warranty coverage or the extended one(usually purchased by an enterprise). So I went online looking for a Battery Cartridge replacement, $300-400!!!, o my! So I decided to try and replace the batteries themselves rather than the entire Battery Cartridge. I was able to find a pack of 8 batteries for around $83 with free expedite shipping. The following steps were what I did to replace each APC RBC43 battery inside the battery cartridge.
Here are some screenshots:
JRE1.7+, grab it here.
md5sum = 6b08f7483fa753f13363b6d0342b379e
SHA1 = 370170c92868ff1b81ac038f85ba22ad929de571
SHA-256 = 6e9ebd0df885ad597512ea2f8e33be38b7af926710547cc3431bcddd1a8b64b5