I have a client that needs SSL to protect online donations, but I have limited experience with how/when to use SSL.
I understand that in purchasing a certificate that I am assigning that certificate to an entire domain (IP address really). Is there a way to isolate the encryption to only a single page of the website, or should I just go ahead and secure the entire site even though only one page needs it?
Unsure of best practice here. Please advise.
SSL incurs quite a bit of extra processing time. For low bandwidth sites, the extra processing required by SSL is not really noticeable. But for sites with heavy traffic like Facebook, Twitter and Flickr, the load caused by SSL is heavy enough that they would have to use dedicated SSL encoding/decoding hardware.
So basically yes, it makes sense to minimize the number of pages using SSL. That is why you often see banking sites only protect the actual account pages via https. The home/landing page is usually plain old http.
On the other hand, unless you really are a site like Twitter or Facebook or Gmail, worrying about this is a bit of a premature optimization. First do it simple if you can. Be aware of this issue and be aware of upgrade strategies when your site finally get heavy traffic.
My boss has a saying:
This is a happy problem to have. First solve the sad problem of
not having enough users then you'd be happy to have a problem that
requires you to refactor your architecture.
You don't encrypt a website with SSL. you encrypt the connection. Therefore if you have SSL enabled for the webserver simply adding https:// to the url will encrypt the connection and whatever page the url points to will be encrypted while in transit.
so
https://www.website.com/index.html is encrypted and http://www.website.com/index.html is NOT encrypted
I prefer for that to never happen so I always put my encrypted pages in a subdomain eg.
https://secure.website.com/index.html
SSL comes with a couple of gotcha's
1/ a basic SSL certificate will only be valid for a specific domain name so if the certificate for is www.website.com and someone follows a link for website.com a warning will be displayed. (see note below)
2/ SSL requires a dedicated IP (which you appear to have). that means you may have problems if you are on a shared platform. this is because in HTTP the host or domain name is part of the headers but the headers are encrypted so the server can't know where to route the request to. (see note below)
It sounds like you really need to employ the services of someone familiar with ecommerce and SSL to help you. navigating the minefield with limited knowledge and forum responses is not the safest thing to do. especially if financial transactions are taking place because there are other requirements that must be considered such as the legal requirements in storing and using financial information such as credit card numbers.
DC
Addendum:
For donations consider Paypal. They have a complete donation solution and more people will trust it than a roll your own solution.
EDIT 2016:
The world moves on and some of the advice above is not as true as it was when originally answered.
SSL no longer requires a dedicated IP address. SNI (Server name indication) resolves that and is almost universal now (IE8 on winXP does not support it and a few phones).
You will find most certificate vendors now include the main domain name as a SAN (subject alternative name) in a certificate. Which is to say they will provide a certificate for both www.website.moc and website.moc if you get a certificate for www.website.moc. Do not assume this, make sure your certification authority specifies it.
also, you mentioned that an SSL certificate protects an IP address. This is incorrect. An SSL certificate corresponds to a domain. Many schemes exist where several domains share a single IP address. If one of these shared domains has an SSL certificate, that certificate is only good for that domain, not the others.
Cookie security is the main thing that I'd point to for your approach.
A user that logs in on your secure login page gets a cookie for their session, right? That cookie's then being transmitted in plain text for someone watching the wire (Firesheep) to intercept and steal the session.
There is additional overhead in terms of negotiation time and CPU load from SSL, but it's rather minimal. If there's anything sensitive going on on your site, just use SSL everywhere.
The other answers are inaccurate in this regard: An SSL certificate binds to BOTH a dedicated IP address that is assigned to a static single domain name, unless you purchase a wild card SSL. Both the domain name and IP must match the certificate.
Related
I have a webapp hosted on firebase hosting at example.com. Firebase provisions a SSL for the root domain. I now connected a ghost blog hosted on heroku at subdomain blog.example.com. I do process credit card payments through my webapp (root domain). Now I am unclear if i should purchase a SSL certificate from third party and provision it with my subdomain(blog.example.com). Is it required for my blog? can it affect my root domain security? WOuld a free SSL from something like Let's encrypt me enough for the blog subdomain .
The short answer is that: No, your blog being unsecured won't affect your webapp's HTTPS security on the root domain (actually called the "apex domain", although usually www.example.com is also made to work the same as the apex domain in web browsers).
When someone visits your secure webapp via the domain example.com, the webapp will present to the client a certificate that is only valid for example.com (and maybe some/all subdomains) that was signed by a certificate authority that most clients keep in their root trust store. This verifies to a decent degree of certainty that the page they are loading is actually from the person/organization that owns the example.com domain. The client/server then do a key exchange and then start enciphering the acutal payload of the HTTP session. This ensures data between the client/server hasn't been modified, and the connection cannot be eavesdropped upon.
You can run other services at blog.example.com or somethingelse.example.com and that wouldn't affect security for users going to example.com.
The plausible reason that you might want to use HTTPS on your blog is if your blog contains links to point users towards your secure site, and you want to make sure users always get directed from those links appropriately. Since your blog is unsecured, anyone with a privileged network position can modify how your blog looks to someone that loads it. State or ISP actors could modify how your blog looks almost anywhere, but even a simpler example of a malicious user at a coffee shop can affect how other browsers at the coffee shop load unsecured sites virtually undetectably. Imagine if your blog contains a link "click here to go to my main site and give me money" but the link was modified to go to a phishing site to allow the attacker to steal users' passwords and/or money.
Only you can decide if this means your blog should have security. While setting up HTTPS can be more work, encrypting everything by default certainly can only help, and many people have undertaken this mantra in the past few years. Certainly Let's Encrypt would be good enough for this.
I am developing a site for a school which will allows students to make an application using PIN and Serial No. I chooses Godaddy to Host the site on Ultimate plan, so is it necessary for me to include Standard SSL for the hosting plans since am using PINS or Standard SSL is meant for secure transanctions that includes using Credit cards?
Do you need SSL?
I assume that said applications will contain personal data, so your web application should use SSL to prevent third parties (such as other people on the same insecure wireless network as the student) from accessing that data. Depending on your jurisdiction, you may also be required by law to enable SSL.
Do you need GoDaddy Standard SSL?
From a quick look, it appears that the product you are referring to is a domain-validated certificate (i.e. they only verify that you own the domain, not that you are who you say you are). You can get those significantly cheaper elsewhere, and if you launch after mid-November, you can get a free one with automatic renewal from the Let's Encrypt project.
You should also check if you can get a certificate from your school. If your application will be hosted under a domain that is already being used for the school, they may have an existing certificate that you can use. Some schools (e.g. most German universities) also have their own certificate authorities which can issue SSL certificates for arbitrary websites.
If you get your certificate from GoDaddy as well, you pay more for the convenience of not having to learn as much.
Is there a https header on the server, or JavaScript method in the browser, that will let us detect when the user has intentionally bypassed the security certificate, or any other way to detect and report this kind of situation? (We are using Linux / Apache / jQuery.)
The Web is filled with ways to routinely skip the warning, but I haven't been able to find a single thing about detecting when users skip it - just the horrifying statistic that 70% of users bypass the warning as quick as they can. (How do they measure that?)
We operate a web application that lets teachers make and administer tests. Teachers are connecting to unauthorized WiFi networks, getting invalid certificate warnings, and clicking on the browser's "accept anyway" feature so they can get to our application despite having certificate that is not authenticated. We want to understand how often this happens, and who is doing it, and progress to stopping it.
I should note that there are schools that proxy requests through their own server, with their own certificate, and we are OK with this - it's the "ignore and connect anyway" connections that we want to measure and mitigate, because those are the ones that students are setting up, without access to their own CA but ample access to lazy users.
One way to make sure that the client has seen the server certificate you sent is to use client-certificate authentication. One of the last steps of the SSL/TLS handshake when using client-certificate authentication consists of a hash of all the handshake messages signed with the client's private key.
A side effect of this is that, if the client didn't see the exact same server certificate, the server wouldn't be able to validate this signed hash coming from the client.
This certainly doesn't necessarily mean that the client checked the certificate as it should have (i.e. whether the certificate was trusted and belonged to the server the client intended to contact), but at least the server has a way there was no fake cert in the middle.
HSTS (which you mention) also has a way to make the client enforce these checks (see Section 8.4 of RFC 6797). However, it only works if the client already knows HSTS needs to be used (either as a pre-loaded host, or after a first visit), and of course relies on the client supporting HSTS (browser support is still limited).
Not sure what you mean by bypassing HTTPS. If you mean they can visit your URI without HTTPS, that means you need to block HTTP access in Apache's .htaccess, httpd.conf, or default-ssl config files. Broken padlock could mean a number of different things so it's not clear which problem you're having. You can test your site for SSL security problems here:
https://www.ssllabs.com/ssltest/
Edit:
You can compare the fingerprint of the SSL certificate on the server and on the client to make sure they match (if the client is able to get the fingerprint). That should prevent man-in-the-middle attacks with bogus certificates.
Article
and here's an answer for doing this on the server side of things. It sounds like the best way to avoid interception is to authenticate the client with their own certificate.
There is no way to detect this - the user is the only one who can see if the padlock is green and locked or red and broken.
Firefox will do this by extension and through xhtml, but it is, as of now, the only browser to support this.
I was looking for HSTS. Here is how it works and how to implement it.
TL;DR: Header add Strict-Transport-Security "max-age=15768000 includeSubDomains"
SSL is very important to protecting users private data on your website.
The more I see SSL used on websites; I have noticed that it is not used all the time like Facebook, Ebay, Google (Youtube) etc...
So my question is: Why pay for a SSL and have the ability to encrypt data while it travels over insecure networks (Internet mainly) then not use it on the whole site?.
Why only encrypt parts of sites?
Why not just force SSL on page load?
It does occur to me that it must be a good reason as it does not slow done the page by having one.
I was thinking of getting a SSL for my website so people can contact me without other people being able to see what they are sending (in case sensitive information really). So should I encrypt the whole site or just that one page.
Thankyou for any help / thoughts on this matter.
Have a good day :)
Why pay for a SSL and have the ability to encrypt data while it
travels over insecure networks (Internet mainly) then not use it on
the whole site?
In theory a webpage over SSL is slower, so some people avoided putting the whole site under SSL.
Should I encrypt the whole site or just that one page.
The whole site would be easier, and I doubt your site would have any problems with performance based on SSL.
I really appreciate your thinking to make your whole website run over encrypted channel with SSL security. Many websites avoid to use ssl on all webpages, but in my personal opinion; if your website contains account log-in and sign-up on every page then it should be protected.
Whether you are running website over HTTP or HTTPS, it rarely affects website loading time & affect your website performances. In current time attacker always try to attack on website anyhow. Secure transmission of data reduces the risk of hacking and allows user to trust upon your website.
im using silverlight 5 and WCF .. and the site is secured with HTTPS . however if i use fiddler , i can see this in the headers:
GET /ClientBin/XXXX-Web-MyService.svc/binary/GetUsers
if i put that directly after my domain : https://www.mydom.com/ClientBin/XXXX-Web-MyService.svc/binary/GetUsers
it will download all data from tabel users. how can i hide and protect this information from being visible!! isn't using SSL enought ? why is this visible anyways if im using https!?
thank you.
EDIT: my initial question was kind of an 'uneducated' one and for that i apologies,
i found more info on the subject and did more research. in this Q on SO there is an explanation to why fiddler is able to decrypt and view requests and responses sent over https.
What is point of SSL if fiddler 2 can decrypt all calls over HTTPS?
and to make things even more difficult, the common solution to this problem is using
"Certificate Pinning"
which requires the use of System.Net.ServicePointManager which is not included in the silverlight implementation of System.Net namespace.
so here i am stuck with an SSL cert. that i paid for that can be "cracked" by anyone with basic knowledge of web debugging.
From a purely Theoretical Computer Science point of view, what you are asking for is near impossible to actually impossible. You would need to implement a trusted platform to protect against the attack.
Now for the Science bit, Concentrate
Okay, so lets start with some basic theory. SSL and thus by extension HTTPS solves a very very specific problem. How do you communicate information over an unsecure NETWORK confidential information with a party you have never communicated with before. In this case, the emphasis is on NETWORK. It does so by solving two problems,
Authentication of the server (the server is who it says it is)
Asymmetric Encryption of key exchange
There is some overlap, to ensure that this is one step. I will focus on the 1st, as this is where fiddler "attacks" your system.
The SSL authentication works on a concept of a web of trust. Your computer has a list of TRUSTED verifiers. These are companies like Verisign, Thawte, Geotrust etc. These companies verify certificates by signing them (complex asymmetric encryption term, but its very like a handwritten signature, hard to forge, easy to verify).
Fiddler works by inserting a new trusted CA (verifier) into your computer. From then on, when you visit an HTTPS site, it will send requests on your behalf, reads it then forwards it back on to you with its OWN SIGNATURE. Since your computer completely trusts this signature, it thinks nothing is wrong.
Now, you want to implement certificate pinning. This IMHO is "bloody awful". It works by telling your software to expect a specific SSL cert. Two reasons why this is bad.
If I can work Fiddler, I can work dotPeek and recompile WITHOUT certificate pinning.
When your certificate gets revoked, your clients won't be able to connect.
Why would your certificate be revoked? If your CA loses their private keys, then they will be obliged to make sure its revoked and a replacement sent to you. Also each and every certificate has a sell by date as well, and must be replaced before they start to smell.
So finally what can you do?
SSL is NOT designed for protecting against what you are doing on your machine. The simpliest way to do what you are asking is to simply wrap your WCF calls in an extra layer of symmetric (or even asymmetric) encryption. But once again. The keys must live somewhere, so your client WILL be able to get the keys from a simple disassemble of your binaries and be able to construct a proxy of their own.
In conclusion
This is pretty much exactly the same as the DRM problem. You want to give your customer access to something on their machine but not show them how it works. If you do manage to solve this problem, do post a follow up, since Sony, Nintendo and Microsoft (to name a few) would be very interested in your findings.