SSL what is it

[scotserve]

If you are interested in your clients security then SSL is a must, there is no legal reason to have SSL installed on your site however certain payment processors insist on it i.e. google checkout

What does it do ?
Well SSL encrypts data sent between your browser and the website you are viewing on an SSL enabled site - you can tell you are viewing a secure link by the HTTPS:// protocol rather than just HTTP:// the server answers on port 443 rather than port 80
This is done so the data being transferred cannot be "sniffed" or intercepted

Why would you want to install one they cost money don't they ?

Yes they do cost but it builds confidence in your site and as customers get more computer savvy they tend to look more at the the likes of security on their data

Does my whole site need to run on SSL

No it doesn't but areas such as registration of details and checkout pages should, most cart software will automatically use SSL pages for the sensitive pages of the site simply by providing the https address

Can I not save money by using my hosts shared SSL

I wouldn't, SSL only encrypts the data between the browser and the server not the storage of that data on the server, this means a bit of a security headache to ensure your data remains only visible to you, secondly it creates no brand recognition for you when your customer is shunted off to "secure.nameofrandomhost.ru" or suchlike - many will bail out at this point because they don't trust or know where they are being sent. 

Can I install SSL myself

You can but unless you have the right permissions in your hosting account you wont be able to - I would also not suggest you do it is something your host should help you install

Why do i need a fixed IP

So the issuing authority can validate the connection the SSL connection is bound on the server to a fixed IP address not other site can use this address, most sites are a shared IP so if you are you need to be shifted to a fixed IP before an SSL can be installed

Prices are different why so

Like everything else related to computers there are a wide range available, there are top industry names like Thawte recognised the world over with very high browser recognition rate, there are others that are much cheaper but may have issues on mobile devices - your host should be able to advise you on what you need

Are there different types of certificate

Yes very much so, there is different types of verification with wildly differing prices, there are certificates that cover all sub domains and there are differing levels of warranty and verification on the certs themselves. For most purposes the small business trader will use a domain verified certificate this means the domain is verified to the owner and the cert is issued - this is adequate to give your customers the feel good factor that you are taking care of their personal details - which of course you are.

Self signed certificates

Totally stupid for a commercial site - the browser will let your customers know that the cert is unsigned meaning there has been no due diligence done on the owner - a big turn off

My host sold me a certificate for <name_of_domain.com> but when it goes to <www.name_of_domain.com> in the browser it tells me that the site is not SSL enabled

Your host's a numpty - unless you purchase a wildcard certificate then your certificate will only cover one leaf of your domain - meaning if you by a cert for name_of_domain.com  then www.name_of_domain.com will not be covered neither will any sub domain you create

So again you can see for the uninitiated there can be a minefield to walk through - there are the sellers that will try to oversell you for your needs and there will be sellers that will try to entice you into the cheap and cheerful because that's all they understand - not all SSL are equal and assessment of your needs and expectations should be taken into account

[Beautybase]

This is on my list of things to organise

So thankyou for a very well written post

[chaoticnrg]

Another great quality and informitive post   





Steve

[ianjofriel]

What does it do ?
Well SSL encrypts data sent between your browser and the website you are viewing on an SSL enabled site - you can tell you are viewing a secure link by the HTTPS:// protocol rather than just HTTP:// the server answers on port 443 rather than port 80
This is done so the data being transferred cannot be "sniffed" or intercepted.
By using an SSL certificate, it does not negate any possibility of network traffic being sniffed, what it does do however, is makes the data useless without the SSL Private Key. Although, determination prevails in this society and SSL, like any other encryption technology is breakable.

Does my whole site need to run on SSL

No it doesn't but areas such as registration of details and checkout pages should, most cart software will automatically use SSL pages for the sensitive pages of the site simply by providing the https address
It's worth noting that the overheads of the encryption and decryption are absolutely minimal, so if  you did decide to have your entire site via SSL, it wouldn't be detrimental in anyway, however, as a benefit, visitors won't get prompted that they are switching between secure and non-secure sites, etc, and there are also security issues cited for including both non-SSL and SSL content on one page. So all in all, it's not altogether such a bad idea.

Can I not save money by using my hosts shared SSL

I wouldn't, SSL only encrypts the data between the browser and the server not the storage of that data on the server, this means a bit of a security headache to ensure your data remains only visible to you, secondly it creates no brand recognition for you when your customer is shunted off to "secure.nameofrandomhost.ru" or suchlike - many will bail out at this point because they don't trust or know where they are being sent. 
Site specific SSL Certs don't encrypt any data locally, they are used to encrypt traffic passing over the internet, not anything stored on the server, by using a shared cert, the vulnerability that presents itself is that other hosts sharing the certificate can easily decrypt your SSL data, think of it as having a block of flats with every door having the same yale key.

Other benefits of SSL go far beyond just Web browsing, TLS as it's now known, can support authentication and validation for a variety of network services that may be available on your web host, such as OpenVPN authentication, Secure Mail Auth, etc

[scotserve]

What does it do ?
Well SSL encrypts data sent between your browser and the website you are viewing on an SSL enabled site - you can tell you are viewing a secure link by the HTTPS:// protocol rather than just HTTP:// the server answers on port 443 rather than port 80
This is done so the data being transferred cannot be "sniffed" or intercepted.
By using an SSL certificate, it does not negate any possibility of network traffic being sniffed, what it does do however, is makes the data useless without the SSL Private Key. Although, determination prevails in this society and SSL, like any other encryption technology is breakable.

Does my whole site need to run on SSL

No it doesn't but areas such as registration of details and checkout pages should, most cart software will automatically use SSL pages for the sensitive pages of the site simply by providing the https address
It's worth noting that the overheads of the encryption and decryption are absolutely minimal, so if  you did decide to have your entire site via SSL, it wouldn't be detrimental in anyway, however, as a benefit, visitors won't get prompted that they are switching between secure and non-secure sites, etc, and there are also security issues cited for including both non-SSL and SSL content on one page. So all in all, it's not altogether such a bad idea.

Can I not save money by using my hosts shared SSL

I wouldn't, SSL only encrypts the data between the browser and the server not the storage of that data on the server, this means a bit of a security headache to ensure your data remains only visible to you, secondly it creates no brand recognition for you when your customer is shunted off to "secure.nameofrandomhost.ru" or suchlike - many will bail out at this point because they don't trust or know where they are being sent. 
Site specific SSL Certs don't encrypt any data locally, they are used to encrypt traffic passing over the internet, not anything stored on the server, by using a shared cert, the vulnerability that presents itself is that other hosts sharing the certificate can easily decrypt your SSL data, think of it as having a block of flats with every door having the same yale key.

Other benefits of SSL go far beyond just Web browsing, TLS as it's now known, can support authentication and validation for a variety of network services that may be available on your web host, such as OpenVPN authentication, Secure Mail Auth, etc

Quite correct it dosent stop traffic from being sniffed but I didn't mean that I meant the data would not be of any use as per your comment

disagree with you point the overheads are higher than normal traffic also the lack of need for the SSl encryption is fundamentally there - most carts support the featiue of SSL encryption of sensitive data while leaving the vast majority of the siite on port 80

Point 3 was as I said - shared hosts have an inherent  problem of encryption as I said SSL goes way beyond what i have discussed - but for he basics and for the normal SSL enquiries it does provide the basis of what an SSL certificate does
 

[ianjofriel]

The largest part of the SSL process is the initial handshake, where the crypto is determined, and given that standard single core processors these days are capable of crypto to several hundred MBits per seconds and it only occurs (technically) at the start of the communication if Keepalives are in operation as per HTTP/1.1, it really is not an issue, most smartphones now have more than adequate processing power to handly TLS/SSL without any degredation, so multi core desktop and laptops really are negligible.

[scotserve]

The largest part of the SSL process is the initial handshake, where the crypto is determined, and given that standard single core processors these days are capable of crypto to several hundred MBits per seconds and it only occurs (technically) at the start of the communication if Keepalives are in operation as per HTTP/1.1, it really is not an issue, most smartphones now have more than adequate processing power to handly TLS/SSL without any degredation, so multi core desktop and laptops really are negligible.

however, as a benefit, visitors won't get prompted that they are switching between secure and non-secure sites, etc, and there are also security issues cited for including both non-SSL and SSL content on one page. So all in all, it's not altogether such a bad idea.

Agreed the overheads are minimal but they are still there
Most hosting these days the Data is the same unlike a few years back when https and http directories were separate so there is absolutely no benefit in having the whole site SSL'd as there is no swapping it is the same data just served on a different port

[ianjofriel]

Most browsers will warn when swapping from a secure to non-secure connection, also, attempting to include any content from an http request in an https request is bad security practice, and in most eventualities, can be stopped by the likes of avast, etc as x-site scripting.

If your concerned about the overheads of SSL, and as I pointed out the initial bulk is the handshake, if your sessions goes https -> https -> https -> https, etc the hand shake will be at the beginning, if you swap between https and http throughout the visit, the handshake needs to be re-established as it will go into teardown once the TLS is no longer needed...

[scotserve]

Most browsers will warn when swapping from a secure to non-secure connection, also, attempting to include any content from an http request in an https request is bad security practice, and in most eventualities, can be stopped by the likes of avast, etc as x-site scripting.

not the point I was making - if you are serving data from your own site then there is no swap - it is the same data unlike a few years back where https data had to be in a separate directory - so in effect if you are reading your own data from your own website you cannot serve non secure data in a secure page, the only way for that to happen would be to put a full http request in the page rather than a directory path.
E.G.
https://www.scotserve.co.uk/img/check.gif  is the exact same image as http://www.scotserve.co.uk/img/check.gif

[ianjofriel]

Most browsers will warn when swapping from a secure to non-secure connection, also, attempting to include any content from an http request in an https request is bad security practice, and in most eventualities, can be stopped by the likes of avast, etc as x-site scripting.

not the point I was making - if you are serving data from your own site then there is no swap - it is the same data unlike a few years back where https data had to be in a separate directory - so in effect if you are reading your own data from your own website you cannot serve non secure data in a secure page, the only way for that to happen would be to put a full http request in the page rather than a directory path.
E.G.
https://www.scotserve.co.uk/img/check.gif  is the exact same image as http://www.scotserve.co.uk/img/check.gif

There is one fundamental difference that makes mixing HTTP and HTTPS fundamentally wrong, you would then be using HTTP traffic on an HTTPS page.

HTTPS as you originally stated is useless to a 3rd party if sniffed off the wire. However, you introduce non-secure traffic, which can be sniffed, therefore, theoritcally open to a man in the middle attack, rendering your security worthless, take the scenario for a second where that img is indeed a .js include, and someone injects some rogue code into it to redirect form data from orders, such as credit card numbers, etc, users are none the wiser because they believe your SSL cert.

[scotserve]

Most browsers will warn when swapping from a secure to non-secure connection, also, attempting to include any content from an http request in an https request is bad security practice, and in most eventualities, can be stopped by the likes of avast, etc as x-site scripting.

not the point I was making - if you are serving data from your own site then there is no swap - it is the same data unlike a few years back where https data had to be in a separate directory - so in effect if you are reading your own data from your own website you cannot serve non secure data in a secure page, the only way for that to happen would be to put a full http request in the page rather than a directory path.
E.G.
https://www.scotserve.co.uk/img/check.gif  is the exact same image as http://www.scotserve.co.uk/img/check.gif

There is one fundamental difference that makes mixing HTTP and HTTPS fundamentally wrong, you would then be using HTTP traffic on an HTTPS page.

HTTPS as you originally stated is useless to a 3rd party if sniffed off the wire. However, you introduce non-secure traffic, which can be sniffed, therefore, theoritcally open to a man in the middle attack, rendering your security worthless, take the scenario for a second where that img is indeed a .js include, and someone injects some rogue code into it to redirect form data from orders, such as credit card numbers, etc, users are none the wiser because they believe your SSL cert.

totally agree with you but thats the point I am making providing you are accessing the page via HTTPS then all the content on that page will be secured unless you are pulling in anything on an http:// path but with modern setup and all files in the same directory structure as long as the paths are relative then no security breach is made - most modern carts allow for the encryption of the relative pages simply by switching the access to https there is no swap of date only way it is accessed.
There is a danger where people insist on dragging in logo's and badges of honour from other sites and a good reason to keep all content within your own server. 

[ianjofriel]

if they are on the same path, yes, they will be https, however, the minute you introduce something that isn't secure onto an HTTPs page you are compromising the certificate.

Therefore if you keep your entire site and redirect all http traffic to https, you will negate the risk, which was the initial point i was trying to make.

[scotserve]

if they are on the same path, yes, they will be https, however, the minute you introduce something that isn't secure onto an HTTPs page you are compromising the certificate.

Therefore if you keep your entire site and redirect all http traffic to https, you will negate the risk, which was the initial point i was trying to make.

I was addressing your point here saying was a good idea to have the whole site running in SSL

It's worth noting that the overheads of the encryption and decryption are absolutely minimal, so if  you did decide to have your entire site via SSL, it wouldn't be detrimental in anyway, however, as a benefit, visitors won't get prompted that they are switching between secure and non-secure sites, etc, and there are also security issues cited for including both non-SSL and SSL content on one page. So all in all, it's not altogether such a bad idea.

Your arguing apples and oranges as if the whole site is running on SSL and all files are within the same site it is a waste of resources however little whereas if you are pulling in content fron non SSL pages it makes no difference whether is a fully SSL'd site as any non secure stuff will still show up. I would repeat if all data is on the site there is no switching to unsecure data so there is absolutely no benefit to running the whole site SSl as you suggest.

[ianjofriel]

I'm not wasting any more time on this, your obviously adamant you know SSL inside out. but I will reiterate as I leave this thread.

If you use SSL on your site, you waste MORE bandwidth by swapping between http and https that staying on one or the other. The minute you start mixing TLS and non-TLS content on one page, you compromise the purpose of the SSL cert, regardless if your data is on the same server or not.

I hope someone else that reads this will understand it the points raised.

[scotserve]

I'm not wasting any more time on this, your obviously adamant you know SSL inside out. but I will reiterate as I leave this thread.

If you use SSL on your site, you waste MORE bandwidth by swapping between http and https that staying on one or the other. The minute you start mixing TLS and non-TLS content on one page, you compromise the purpose of the SSL cert, regardless if your data is on the same server or not.

I hope someone else that reads this will understand it the points raised.

Jeeze get off the high horse and listen for a minute to what i am saying - I am not disagreeing with you on mixing content but on most servers these days the content is not mixed it is the same content
Some years ago you had 2 directories one for https and one for http, when the request was made to port 443 then the https directory was accessed and yes there was a major issue in mixing content but this does not happen anymore the content is not split anymore and http and https traffic is the exact same data it does not switch directories or locations it serves the data on either the ssl or non ssl port so what i am arguing is there cannot be any benefit to running an entire site in SSL

FTR I dont know SSL inside out but I do setup hundreds of SSL enabled sites and i know what works and how it works, I am also a Thawte and Comodo authorised reseller