Securing the business transactions, and customer information is critical for business success and wining the customer’s trust.
In this article we will cover some of the basic concepts that you should know as a start to secure your business transactions.
Here are the topics we will cover:
- When to use secured connection and when to use non-secured connection?
- Definition of Symmetric and Asymmetric encryption?
- What is Security certificate?
- What happens when accessing HTTPS page from the browser?
- KeyStore and TrustStore
1. When to use secured connection and when to use non-secured connection?
You should consider the secured connection (ex. Https) in the following situations:
- The traffic sent/received contains critical info such as personal data (name, address, phone number, birth date, email address, …), credit card info, …, etc.
Why? the information might be target for man-in-the-middle attack from inside or outside the network, so the data from this types must be always encrypted to make sure that it is not readable if intercepted.
- The Web service is being called from the internet or from outside of the network.
why? Exposing the web service to the internet will increase the risk of man-in-the-middle which can lead to data leakage. Using secured connection will encrypt the data, and verify the identity of the calling server.
Note: The test servers must have the same level of security if it is a replica from the production server as it will contain critical data.
You should consider the non-secured connection (ex. HTTP) in the following situation:
- The web service is called only within the internal network, and no sensitive data is being transferred.
Explanation: The internal network is already protected by the network firewall and the DMZ (demilitarized zone).
- The web service will return non-sensitive data. Ex. a web service returning the weather forecast, the forecast is available for everybody anyways (there is nothing to hide).
2. Definition of Symmetric and Asymmetric encryption?
- Symmetric Encryption Algorithm: is encryption algorithms which use the same key to encrypt and decrypt the data. Examples: AES, DES, 3 DES
- Asymmetric Encryption Algorithm: is encryption algorithms which use a pair public and private keys. The data encrypted by the private key can be decrypted only by the matching public key, and the data encrypted by the public key can be decrypted only by the matching private key. The public key is shared with everybody, and the private key will be only with one entity (everybody can send me a message encrypted by my public key, and the message can be decrypted only by my private key). Examples: RSA, ElGamal, Deffie-Hellman.
3. What is Security certificates?
- Security certificate contains information about a specific server (certificate serial number, expiry date, organization name, issuer of the certificate, public key of the server, IP or name of the server as called by the client, … etc), The security certificate can be issued by Certification authority (CA), or self-signed.
- Certification authority (CA): is the certification authority which is responsible for granting and signing the certificates after verifying the requestors information, revoking the compromised certificate. Examples: VeriSign.
- The certificate issued by CA is trusted and it recognized by the web browser, so users can trust it. All the production server must use security certificate signed by the CA. The self-signed certificate contains the same information as the one signed by the CA except that it was created by the developer or the company owning the server so when dealing with the production server there is no way to guarantee the identity of the server and your data will be at risk.
- Usually you can use self-signed certificate for the development, and test servers. But for the production it is strongly recommended to use a certificate issued by CA.
- The security certificate is issued for a specific IP or address and can’t be used to other servers. Example: if the certificate was for localhost and you used 127.0.0.1 (which is the IP of the localhost), it will not work as it is considered a different server.
4. What happens when accessing HTTPS page from the browser?
In this section we will discuss what happens when you access HTTPS page through your browser.
1. When you type the address, the browser will check the certificate of the target server to make sure that it is valid, and signed by known CA. If not, the browser will notify you that the page is not trusted.
The following is print screen from the page of Bank of Montreal (BMO) login, the browser is showing that is trusted web site and by clicking on the lock beside the address bar and you can see the certificate details.
2. Your browser and the server will perform some requests which called the handshake to agree on the Encryption algorithm used and the encryption key used in the session(random key changes with each session). During the handshake the browser will use the server’s public key to encrypt/decrypt the messages, and the server use the private key to decrypt/encrypt the messages.
3. After the browser and server agree on the algorithm and key, they will use symmetric algorithm (stated in the handshake) and the encryption key(stated n the handshake) as the symmetric encryption is faster that the asymmetric algorithm (public/private key).
5. What are KeyStore and TrustStore?
- Key Store: Is password protected file which contains the private key and a copy from the security certificate of your server. So your server can use it to sign the messages/traffic sent with the private key to that the message was not altered during its way to destination, and can decrypt the incoming traffic encrypted by the servers public key.
- Trust Store: IS a password protected file which contains the root CA certificates that you recognize. So your server will accept the traffic from any server which has a certificate signed by the root CA certificate which exists in the trust store. For example if you added the root certificate of VeriSign in your truststore you will accept the traffic from any server has a certificate signed by VeriSign.
Technically the key store, and trust store is using the same technology and the only difference how to use it in your application. Example for famous store formats are:
1. JKS (Java key Store).
Next time we will see how we can create a security certificate request (CSR), and generate a self-signed certificate.
Thank you for visiting our website. We are looking forward reading your comments and questions.
on twitter: @WM_Expert
Group on LinkedIn: webmethodsExpert.com
(C) 2014 Hossam Elsharkawy. All rights reserved.
11 thoughts on “Secure connection – part 1- Introduction”
Thanks.. very informative and simple
You are welcome.
Valuable information, thanks for your efforts 🙂
thank you very much
Its really good to understand from basic level of certificates
you are writing “The security certificate is issued for a specific IP or address and can’t be used to other servers. Example: if the certificate was for localhost and you used 127.0.0.1 (which is the IP of the localhost), it will not work as it is considered a different server.”
Does this apply also vise versa? I mean if I change server IP address will certificate stop working? We have SSL certificates in use with IS servers and we might need to change IP addresses during the move from one datacenter to another. I think some of those IP addresses we use are also public.
Yes, it is vice versa. You have to check if the certificate is issued with the server ip or with server alias. If it is issued for the ip then you have to change the certificate as well. But if you are using the server name or server alias(resolved with network using DNS) then you don’t have to change it as long as you keep using the server alias.
The conclusion is: how your server is called will decide what you are going to do. The certificate should be issued for the name used to call the server.
Best practice: it is recommended to create an alias for the server which will be used to call your server. This approach will give you the flexibility to change the ip or the physical server without creating a new certificate as long as you use the same server alias.
We are looking forward answering any questions you have.
Excellent…So much valuable information. Thanks!
Thanks for this Tutorial .it is good and clear