Security - What is in a handshake
From All n One's bxp software Wixi
- 1 Overview
- 2 Connection
- 3 Security challenges
- 4 bxp related articles
- 5 Current Ciper Suite on bxp
This article goes into some of the detail of what happens when you first connect to bxp at a technical level and provides links to relevant material. This is considered a very technical article for those who really want to delve into security of bxp.
The article describes what happens when you open your browser and go to ww3.allnone.ie/demo
2.1 The browser
First thing is the browser that you use will need access to the Internet. We're going to assume this is in place. As part of this your operating system will have access to public DNS records. Your system will translate ww3.allnone.ie into 188.8.131.52
2.2 The protocol
If you connect to bxp via http on port 80, all of the pages have intelligence to redirect your URL to the https equivalent and swap you seamlessly to port 443. No processing at all is done on a http connection.
2.3 The handshake
In order for you to get the web page, a secure https handshake is performed.
As part of the ClientHello a number of details are sent by your browser to the server.
- ClientVersion 3,1
- SessionID: None (new session)
- Suggested Cipher Suites:
- Suggested Compression Algorithm: NONE
Those Cipher Suites are encryption methods. There are many available. See below for the suite currently supported by bxp
bxp responds with a ServerHello and the selected suite to use
- Version 3,1
- SessionID: bd608869f0c629767ea7e3ebf7a63bdcffb0ef58b1b941e6b0c044acb6820a77
- Use Cipher Suite:
- Compression Algorithm: NONE
As part of this, the server sends a public key for the client browser to now encrypt all communications with.
Using the public server key, the client encrypts and responds, sending the client's public key.
The server sends a complete encryption of the transaction to date, using the client public key and now data can begin to pass.
The current Cipher suite used for the end users connection to the load balancer is as follows:
The LoadBalancer will automatically choose a cipher in the encryption based on queue order and compatability.
3 Security challenges
3.1 Browser protocols
Different browsers support a number of encryption suites. Imagine it like a language. The options most commonly available are.
- SSL 1.0
- SSL 2.0
- SSL 3.0
- TLS 1.0
- TLS 1.1
- TLS 1.2
For security reasons and the ease of mathematics, all the SSL methods currently are easily unencrypted using brute force hacking.
Even TLS 1.0 is not considered secure as using brute force hacking could still break it in a reasonable amount of time.
TLS 1.2 is the target.
IE6 only supports up to TLS 1.0 and must be turned on explicitly.
3.2 Encryption Algorithms
Within the language are encryption methods. These vary in complexity. Some encryption methods are stronger than others. The protocols make use of these algorithms.
Here is an extensive listing of the encryptions (cipher suites) available for each protocol.
As security improves, it is important to check how secure your protocols and suite are. Qualys provide an excellent testing tool. https://www.ssllabs.com/ssltest/
Windows 2000 has none of the algorithms used by TLS 1.2, so even if you install a modern browser which can do TLS 1.2 on a Windows 2000 machine, it doesn't have the maths to do the encryption. Windows XP can do TLS 1.2 with Service Pack 3 or 4 installed.
3.3 Secure Hashing Algorithms
As a generic approach to writing an encryption algorithm, SHA-1 gives rise to most of the SSL through TLS 1.0 cipher suites.
TLS 1.2 needed a more complicated algorithm which is called SHA-256, or SHA-2 for short.
There are many variants within these titles.
5 Current Ciper Suite on bxp
This cipher suite shown above is from the connection from user to the load balancer. This list shown below is the current cipher suite from the load balancer to the web server. Different various of security is used to mitigate possible intrusion or cipher cracking.