|Home||Pauline's Pages||Howto Articles||Uniquely NZ||Small Firms||Search|
|SSL and all that|
Many small business will need some form of secure communication with their clients so that they can take orders or deposits using Credit Cards over the Internet. The most usual way is via Forms as few of your customers will have the ability to send encrypted email. The Internet is however much less private than, for example, telephone. The connection between you and any other point on the Internet can, and usually is, routed through many independent computer systems. You must consider non-encrypted email, web browsing, forms and any other Internet communication as potentially insecure as you have no idea how the information will be routed and the routing will vary every time - it is easy for someone to monitor all the traffic through a machine and look for the typical pattern of a credit card number and the chances are they will also pick up all the other details such as name address, expiry date etc. The answer is encryption, in particular data interchanged using forms.
The most common way to interchange secure data is to use the SSL (Secure Sockets Layer) protocol which was developed by Netscape to provide security and privacy over the Internet. By convention, Web pages that require an SSL connection start with https:// instead of http:// . Recent versions of both Netscape Navigator and Internet Explorer support SSL. The SSL protocol maintains the security and integrity of the transmission channel by using encryption, authentication and message authentication codes using public and private key combinations.
For those who want to know the technicalities, the SSL Handshake Protocol consists of two phases: server authentication and an optional client authentication. In the first phase, the server, in response to a client's request, sends its certificate and its cipher preferences. The client then generates a master key, which it encrypts with the server's public key, and transmits the encrypted master key to the server. The server recovers the master key and authenticates itself to the client by returning a message authenticated with the master key. Subsequent data is encrypted and authenticated with keys derived from this master key. In the optional second phase, the server sends a challenge to the client. The client authenticates itself to the server by returning the client's digital signature on the challenge, as well as its public-key certificate.
The Web server obviously needs to have the SSL protocols installed and it will only work compatible browsers. These days, most browsers do support SSL, but, in particular, some versions of AOL's browser don't and many of the browsers outside of the USA do not support the strongest encryption standards using long key lengths. Some older browsers also need minor updates to make them work. You will also see mentions above of digital certificates. These are important to your customer as they are the way he ensures that he is sending to the right person/firm - it is no use sending the highly encrypted details of ones credit card if it is straight to an imposter. these Digital Certificates for SSL transactions are provided by a number of bodies who carry out stringent checks to authenticate the firm -The ultimate result of SSl and Digital Certificates is safe on-line transactions that protect customers and your business where customers have confidence that they are sending their personal information to a legitimate business and not an impostor in a way that ensures that information cannot be viewed if it is intercepted by unauthorized parties or altered on route.
Setting up SSL on a server is quite complex, expensive and time consuming for a small firm and the bodies issuing Digital Certificates for SSL often insist that they are installed on dedicated (not shared) servers which is even more expensive. A number of hosting firms are getting round this by purchasing and installing a Digital Certificate and installing it on a dedicated server but allowing a number of sites to share access to the server for secure transactions. This does compromise security a little but the result is still good enough for credit card transactions. Other hosts such as Hypermart seem to have got round the dedicated server constraint and have a Digital Certificate and SSL installed on every server but have extra controls on accessing it - see the Report on Hypermart. The weak link is rarely in obtaining the data but is in storing it, accessing it and using it.
Most customers will be completely unaware that the secure transactions are using some common facilities although they will be able to see the URL is different for the page using the secure form and the confirmation page(s) - this is common on even the largest sites to improve security so does not matter. Few customers will go as far as to check the Digital Certificate itself and will put all their faith in the little "padlock" or similar in the status display in the Browser.
We have now got as far as a very secure link between the customer and the Browser when he fills in his form and sends it and the script file which handles it will also be on the secure server or secured space on a server. The weak links are in what is done with the data by the script. Most form processing scripts then email the information to a standard POP3 mail box - this should ideally be on the same server or certainly on a server in the same location to minimise the chances of the email being routed through insecure machines where it could be intercepted. The same applies to collection from the mailbox - there is no point in taking great care of the information then collecting the mail via a Dial Up Network connection routed through an unknown number of insecure machines - you must always collect via the hosts own connection where you phone straight into a modem on his internal network. If you can not meet these conditions the output of the forms must be sent to a file which resides on the server in a password protected area that only you can access via FTP - very time consuming and not very user friendly. The alternative of sending an encrypted email is not supported yet as far as I can discover by any hosts providing a cheap shared SSL space.
The weakest link of all is arguably on your own machines where all the card details of your customers may well reside in an easily accessible form often without any password protection of the machine or data. If the machine is stolen or if staff can access the machines there is obviously a real risk. Service engineers may also need access and if a machine is sold they all the data needs to be deleted securely which is difficult. Most customers fortunately do not concern themselves beyond the point of the initial secure transaction but one should still take care. There are some good free encryption programmes such as PGP which enable you to set up a secure area to hold such data as well as your important financial data for the business. PGP (Petty Good Privacy) is covered in a separate article on Secure Storage and Email
Peter and Pauline Curtis
Most recent significant revision: 2nd September, 2000