We talk about firewalls and proxies and their rules to secure access to your resources. But have you ever wondered, what is the underlying mechanism, to secure your traffic between requests (browser) and responses (server)? Well, the answer is Secure Sockets Layer (a.k.a SSL).
Are TAs expected to setup SSL/TLS?
Nope, they are not. However, TAs are expected to understand how SSL/TLS works. If you ever get stuck with issues related to certificates/security. You (as a TA) are expected to co-ordinate with client’s technical teams to tell them what needs to be done? to resolve the issues.
What is SSL?
TLS and its predecessor, SSL, are cryptographic protocols that provide communication security over the Internet.
SSL was developed by Netscape and if you google and check its history, you will be astonished to know that its first version was never used and second version was hardly used and its third version (SSL3) enjoyed little adoption and usage.
And you will be equally amazed to know that actual SSL technology (developed by Netscape) is no longer used. It’s just the name that floats around but the fact is actual SSL technology is no more used. Instead a new technology has emerged and is widely used these days. It’s called Transport Layer Security (a.k.a TLS).
How do I secure my server resources with SSL?
Just install the server certificate on the server and make sure that your application applies that server certificate to itself, thats it. Your application resources will be secure. Once installed, SSL will allow HTTPS:// to function on server.
What is a certificate?
In simple words, a Certificate is block of information in a cryptographic manner, essentially telling the other computers that I am who I say I am. Certificates are used for either authenticated single sign-on with an external website, or when using your organization as an identity provider.
- You only need to generate a Salesforce.com certificate if an external website needs verification that a request is coming from a Salesforce.com organization. (I.e. your Salesforce instance).
- You can generate a self-signed certificate (signed by Salesforce) or a CA-signed certificate (must be sent to a CA[Certificate Authority] to sign)
What is a two way certificate or client certificate?
In some cases HTTPS:// is not sufficient. After the initial security handshake is done, the customer might expect salesforce.com to prove that it actually is salesforce.com when salesforce.com is calling a customer resource. A couple of examples of that are:
Salesforce sends client certificate as part of
- Outbound messages
- Delegated authentication callout.
Some important things to note are:
- In salesforce, custom client certificates can be created and used within the app.
- Salesforce does not expect your client applications to send client certificates to salesforce. But Salesforce does send a client certificate as part of every outbound callouts, outbound messages, etc.
How does it work?
One important ground rule is, both client and the server should support SSL/TLS for a secure communication to happen. If browser supports and server doesn’t, then the connection cannot be established and communication won’t happen.
Since protocols (HTTP, FTP, etc..) can operate either with or without TLS (or SSL), it is necessary for the client to indicate to the server whether it wants to set up a TLS connection or not. There are two main ways of achieving this; one option is to use a different port number for TLS connections (for example port 443 for HTTPS). The other is to use the regular port number and have the client request that the server switch the connection to TLS using a protocol specific mechanism (for example STARTTLS for mail and news protocols).
Once the client and server have decided to use TLS they negotiate a stateful connection by using a handshaking procedure. During this handshake, the client and server agree on various parameters used to establish the connection’s security. Here are some of the initial events that occur during a secure communication.
- The client (browser) sends the server the client’s SSL version number, cipher settings, session-specific data, and other information that the server needs to communicate with the client using SSL.
- The server sends the client the server’s SSL version number, cipher settings, session-specific data, and other information that the client needs to communicate with the server over SSL. The server also sends its own certificate, and if the client is requesting a server resource that requires client authentication, the server requests the client’s certificate.
- The client uses the information sent by the server to authenticate the server. If the server cannot be authenticated, the user is warned of the problem and informed that an encrypted and authenticated connection cannot be established. If the server can be successfully authenticated, the client proceeds to the next step.
Hope that’s helpful.
Afzal's Blog 