I am bulding a marketplace which store users session ect.... I just added a SSL encryption for login and for the payment (I am using stripe as a payment gateway). I have seen sites like facebook forcing HTTPS on every page so that got me wondering, should I force HTTPS on every page or just on login and payment?
side note, apparently SSL encrypted pages load faster
Yes. But not just because it loads faster, or even ranks better on Google than non-HTTPS sites, but mainly because of security. Having HTTPS makes it harder to do a man-in-the-middle attack, whereby an attack intercepts the connection between your website and the user to either steal or modify data. The trouble with HTTP is that it is possible for someone to do exactly that, and then modify the links to point to a fake login page to steal data (this souunds paranoid but it happens).
While many pages use a script to check if the user is attempting to access HTTP and then redirect them to a HTTPS version, this might still be an issue for websites as attackers can still 'strip' out any HTTPS links (known as the SSLStrip attack) to use only HTTP and then view the data, take a look at enabling HSTS (HTTP Strict Transport Security) for enhanced security to avoid that. This is done by forcing browsers to only interact with the website on HTTPS connections and avoid any sort of downgrade attack.
Related
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.
Is there a reason why a website such as Twitter serves all pages over HTTPS? I was under the impression that the only pages that need to be served over an encrypted channel are pages where sensitive information is being submitted or received.
I do that when developing web apps. It makes securing user data much simpler, because I don't have to think about whether or not confidential information could be passed through a particular request. If there is a performance penalty, it's hasn't been bad enough to make it worth my while to start profiling. My projects have been fairly small, in terms of usage, so far.
Every page on Twitter either:
Is accessed when you are logged in and sending credentials in the request (and potentially receiving data that is private) or
Contains a login form (that shouldn't be interfered with via a man-in-the-middle attack).
Consequently every page on the site has the potential to be a page where sensitive information is being submitted or received.
Switching between HTTP and HTTPS can be tricky to do correctly.
If any resource that is served over HTTP requires authentication, some form of authentication token (typically a session cookie) will be leaked from HTTPS to HTTP (assuming the user authentication itself is done over HTTPS).
Getting the flow of pages right so that, once that token has been used over plain HTTP, it can no longer be relied upon for anything more sensitive (which would require HTTPS) can require a lot of planning in the design of the application. (There are certainly a number of websites that don't do it properly.)
Since Twitter is a website where you're always logged on (or always have the opportunity to log on securely in the corner), it seems to make sense to use HTTPS for everything.
The main overhead in HTTPS is the SSL/TLS handshake: checking the certificates, asymmetric cryptography, ... Once the connection is established, it's all symmetric cryptography, with a much lower overhead.
You'll see a number of questions here (and other places) where people insist to have redirection rules to force plain HTTP for resources that don't need to be used securely, while forcing HTTPS for other pages. This seems misguided to me: by the time the redirection from HTTPS to HTTP happens, the handshake has already taken place. A good browser will keep the connection alive (and will be able to reuse sessions) to get multiple resources and pages, thereby keeping the overhead to a minimum, almost negligible at that point.
When People buy SSL Certificates for their websites, they can use it for all Pages in the domain. Why then they use it for selective pages only.
Typically you will find that all E-Commerce Solutions like Magento, ZenCart etc will have settings for Secure Page and Insecure Page.
They will typically have their Checkout and Payment Processing related pages secured using https while all other parts of the site will remain insecure.
Does using SSL in all Pages has a Performance Overhead? As in the Load on Server will increase if you used SSL in all Pages?
How will a Customer, Vendor, Payment Processor gain Confidence in your site if you didn't use SSL in your Home Page? As they will probably land in your Home Page only.
While it's true that encrypting public information is not as valuable, it's not the case that it's worthless because it provide authenticity.
Consider the New York Times website. It's not encrypted because all the information is public. However, if you were to MITM the WiFi network at a major financial conference and inject stories about a market crash, that could be an effective attack against the authenticity of the page.
Additionally, if forms are on unencrypted pages then it hardly matters if they submit over HTTPS because the attacker can rewrite the action URL and the user is none the wiser.
Basically, you only need to use SSL when you post and get data from the server which are sensitive.
There is no benefits to be SSL on a static web site that only throw general and public information to the browser.
SSL encrypt the data on the Request and response so yes, your performance can suffer for nothing on the static part of your web site.
I'm running a dating site and not using SSL at the moment.
I've noticed major sites like facebook and twitter do not use https for login but just use plain old http, is there really any advantage to https-ing my site or it is only for cc transactions or so ?
thanks in advance.
Actually, facebook does use https for its login:
<form method="POST" action="https://login.facebook.com/login.php?login_attempt=1" id="login_form">
as does twitter:
<form method="post" id="signin" action="https://twitter.com/sessions">
You'll notice they don't use https for the page that displays the signin form. That's because it isn't necessary.
However, it's a good idea to use ssl the login itself if you can, if only because so many users employ the same password for all sites.
One solution, which I'd like to see more sites employ, is using OpenID/OAuth for login instead of requiring a username/password.
SSL encrypts the traffic between the browser and the server. So virtaully anything you want to be secure needs to be ssl'ed. Google search is even doing it so poeople can't have their search terms intercepted.
Its just the case of what YOU want secure, and if not having certain parts of your site secure will keep wanted customers away. I would think a dating site has a lot of personal demographics information that some people might want secure... just my 2 cents.
SSL is used only when transmitting sensitive data between browser and server. It's fine for major sites like facebook and twitter to use http (as long as the data is not sensitive). Most website use SSL for their login page. SSL also used by payment gateway to safely transfer payment information through the wire.
And by the way, http is not "plain old" and https is not new trend either :)
If your users are providing any sensitive data, ssl prevents it from being intercepted by a third party. If you don't use SSL, you should assume that some third party can see everything that every one of your users does on your website. If you are comfortable with them seeing this information, then keep it plain http, but if you don't like that thought, go https.
Another benefit of ssl is that it allows the use of Strict Transport Security, which not only forces https on all site activity, but also prevents a man in the middle from spoofing your site to a user and making them think they are accessing your site. Details here: http://en.wikipedia.org/wiki/Strict_Transport_Security
I work at a major ISP and am infatuated with one of your online members. By sniffing your packets, I can find out when and where she's meeting another member, rewrite the packet to change the location so the other guy doesn't show up, and then make my move.
You decide whether that's acceptable to your users.
Https is useful to protect the credential (user/password) , but it increases the network load and requires more CPU resource (encryption). Thus, it is common to use only for authentication.
Https ,with server certificate protects again phising.
Banks uses end to end application
I note that some sites (such as gmail) allow the user to authenticate over https and then switch to http with non-secure cookies for the main use of the site.
How is it possible to have http access to a session but this still be secure? Or is it not secure and hence this is why gmail gives the option to have the entire session secured using https?
Please give an example of how this works and avoids session hijacking attacks, whilst still allowing access to authenticated content over http. I want to be able to implement such a scheme if it's secure, to avoid having to have a whole site as https for performance reasons.
As Thilo said, but I'll explain a little further :)
A webserver is stateless! This is really the problem of the authentication-case. You can't just log in, and then say "from now in, this user is logged in" - you need some way to identify which user it is that's requesting a new site this time.
A common way of doing this is by implementing sessions. If you packet-sniff your network traffic while logging into, and then browsing a site you'll commonly notice something like this:
Logging in: You will transmit your username and password to the server. Completely unencrypted! (SSL / HTTPS will encrypt this request for you to avoid man-in-the-middle attacks)
Response: You will receive a randomly generated string of a lot of weird characters. These will typically be stored in a cookie.
Request of some site only you should have access to: You will transmit the randomly generated string to the server. The server will look this string up, and see that it's associated with your session. This allows the server to identify you, and grant you access to your sites.
.. Now, HTTP in itself is not secure. This means that your password and your session-cookie (the randomly generated string) will be transmitted completely un-encrypted. If someone has access to your traffic (through trojans, router hijacking, whatever), he will be able to see your username / password when you log in, if you're not using HTTPS. This will grant him access to your site untill you change your password (unless he changes it first :P ). In the rest of the requests he will be able to get your session cookie, which means he could steal your identity for the rest of that cookie lifecycle ('till you log out, or the session expires on the server).
If you want to feel secure, use HTTPS. Realistically though, it's a lot easier to social engineer a keylogger into your computer than it is to read all your traffic :)
(Or as others have pointed out, use cross-site-scripting to read your session cookie)
It is only secure insofar as the password is not transmitted in the clear. It is possible (and has been done) to intercept and abuse the GMail session cookie in HTTP mode.
To avoid session hijacking, you need to stay in HTTPS mode (which GMail now offers, I think).
This is just a tiny bit more secure than plain HTTP - the login name/password doesn't go over the wire in plaintext. Apart from that, it works exactly like a normal HTTP cookie-based session (because that's what it is); therefore, all the session hijacking issues apply.
It's not really possible and not secure. That's why we got "secure cookies". Although it's good against passive sniffing attacks because username/password won't be exposed however session hijacking is still possible.
Also check out this SSL Implementation Security FAQ paper.