I have a website that makes heavy use of AJAX. There is an almost constant transfer of sensitive data.
Because of this I was thinking of running my full website in HTTPS, making it secure throughout your stay.
I was wondering if there are any downsides doing this. Performance is a huge issue for me, the faster the app runs the better. I can safely say that speed is a larger issue than the security.
On the security side, I already generate a new session id when sensitive data is transfered,so there is no real need to make it all https, but if there are no downsides why not use it.
Can someone please explain to me what the downsides are of using https for everything.
Well, there is obviously the overhead of encrypting everything all the time. It's probably not a huge problem for the client (since it's only encrypting data for a single connection) but it can become a bottleneck on the server (since it has to encrypt everything for every connection).
You could implement an SSL proxy where you have a front-end web server that talks SSL to clients and then forwards requests to the "backend" webservers for real processing. The backend webservers would be firewalled and not use SSL.
Related
I am trying to find (or write) a caching proxy tool that accepts all traffic from a specific container in my localhost (using Iptables). What I want to do with this traffic is to save it and cache the response, and later, if I see that a request was already sent to a server, return the cached response to the requesting party (and not sending the request to the server again, because a previous similar request was already sent).
Here's a diagram to demonstrate what I'm trying to do:
I'm not sure exactly how big is the problem I'm trying to deal with here. I want to do it for all traffic, including HTTP, TLS and other TCP based traffic (database connections and such). I tried to check mitmproxy, and it seems to deal pretty good with HTTP and the TLS part, but intercepting raw TCP traffic (for databases etc.) is not possible.
Any advices or resources I can use to accomplish that? (Not necessarily in Python). How complex do you think this problem is? Do you think I can find a generic solution?
Thanks in advance!
Some time ago, I needed HTTPS support for my express webserver. I found a tutorial that teached me a cool trick to achieve this. They basically explained me that an AWS load balancer can redirect HTTPS to HTTP.
So, I first created a load balancer.
And then redirected HTTPS to HTTP. The traditional HTTP, I just redirected 80 to 80. And I have a websocket (socket io) thing going on port 1337 (which I plan to change to port 1338 in the near future).
Just for clarity. I didn't really need a load balancer, since I actually only have 1 AWS instance. But using this setup, I did not have to go through the trouble of messing around with HTTPS certificate files, neither did I have to upgrade my webserver. It saved me a lot of trouble at first.
Then this morning, I received the bill, and discovered that this load balancing trick has a price tag of roughly 22usd/mo. (an expensive port forwarding trick)
I probably have to get rid of this load balancer. But I am wondering, perhaps I did something wrong in the configuration.
It's strange that charges are so high for a web app that is still in development. So, I am wondering if perhaps there is something wrong with my setup. And that leads me to the following question.
I noticed that I am actually using an old ELB setup: "Classic load balancer". And it actually states that this setup does not support websockets, which is a bit strange.
My web app hosts some static webpages (angular), but once it is downloaded, all traffic uses socket.io websockets. Even though the AWS documentation says that websockets are not supported, it seems to work fine. Unless ...
Now, socket io is a pretty smart thing. When it can't use modern websockets (e.g. because the webbrowser does not support it), it falls back to a kind of HTTP polling. I guess that means that from a load-balancer point of view, it creates 100s of visits per minute. And right now, I am wondering if that has an influence on the charges.
My really long question comes down to a simple one. Do you think upgrading my load balancer would decrease the number of counted "loadbalancer hours" ?
EDIT
Here are some ELB metrics. They are too complicated for me to draw conclusions. But perhaps some of you experts can. :)
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How much overhead does SSL impose?
I recently had a conversation with a developer who told me that having SSL implemented site-wide puts 300 times the load on the server. Is this really credible? I currently use SSL across all pages and we have several thousand users accessing the system daily without any noticeable lag. We are using an IIS 7 server.
His solution was to only use SSL on the login page to secure the transmission of the login credentials. Then redirect them back to HTTP...Is this good practice?
What's costly in HTTPS is the handshake, both in terms of CPU (the asymmetric cryptographic operations are more expensive) and network round trips (not just for the handshake itself, but also for checking the certificate revocation). After this, the encryption is done using symmetric cryptography, which shouldn't impose a big overhead on a modern CPU. There are ways to reduce the overhead due to the handshake (in particular, via session resumption, if supported and configured).
In a number of cases, it's useful to configure the static content to be cacheable on the client-side too (see Cache-Control: public). Some browsers don't cache HTTPS content by default.
Increasing the server's CPU load by 300 when using HTTPS sounds like something isn't configured appropriately.
His solution was to only use SSL on the login page to secure the
transmission of the login credentials. Then redirect them back to
HTTP...Is this good practice?
A number of sites do this (including StackOverflow). It depends on how much security is required. If you do this, only the credentials will be secured. An attacker could eavesdrop the cookie (or similar authentication token) passed in plain HTTP and use it to impersonate the authenticated user.
Great care needs to be taken when switching from HTTP to HTTPS or the other way around. For example, the authentication token coming from the login page should be considered as "compromised" once passed to plain HTTP. In particular, you can't assume that subsequent HTTPS requests that still use that authentication token come from the legitimate user (e.g. don't allow it to edit 'My Account' details, or anything similar).
He is making it up. Surely it occurred to you that 300 is a suspiciously round number? Ask him to prove it. Test and measure.
It certainly puts more load in the server, most of which can be offloaded to a hardware crypto accelerator or a front-end box if you really have a problem, but in my experience it is negligible. See here for more information.
His suggestion about reverting to HTTP after the login only makes sense if the login page is the only page in the site that you want transport security for. This is unlikely to be the case.
Frankly he doesn't appear to know much about any of this.
I did a large experiment about 15 years ago which showed that over the Internet the time overhead of SSL is about 30%.
I'm building a web-based chat app which will need to make an AJAX request for every message sent or received. I'd like the data to be encrypted and am leaning towards running AJAX (with long-polling) over HTTPS.
However, since the frequency of requests here is a lot higher than with basic web browsing, I'd like to get a better understanding of the overhead (network usage, time, server CPU, client CPU) in setting up the encrypted connection for each HTTPS request.
Aside from any general info/advice, I'm curious about:
As a very rough approximation, how much extra time does an HTTPS request take compared to HTTP? Assume content length of 1 byte and an average PC.
Will every AJAX request after the first have anything significant cached, allowing it to establish the connection quicker? If so, how much quicker?
Thank you in advance :-)
Everything in HTTPS is slower. Personal information shouldn't be cached, you have encryption on both ends, and an SSL handshake is relatively slow.
Long-polling will help. Long keep-alives are good. Enabling SSL sessions on your server will avoid a lot of the overhead as well.
The real trick is going to be doing load-balancing or any sort of legitimate caching. Not sure how much that will come into play in your system, being a chat server, but it's something to consider.
You'll get more information from this article.
Most of the overhead is in the handshake (exchanging certificates, checking for their revocation, ...). Session resumption and the recent false start extension helps in that respect.
In my experience, the worse case scenario happens when using client-certificate authentication and advertising too many CAs (the CertificateRequest message sent by the server can even become too big); this is quite rare since in practice, when you use client-certificate authentication, you would only accept client-certificates from a limited number of CAs.
If you configure your server properly (for resources for which it's appropriate), you can also enable browser caching for resources served over HTTPS, using Cache-Control: public.
I'm trying to determine how much of a security risk I'm looking at
when I have rubycas itself running over https, but my actual sites
running under http. the reason I'm faced with this issue is that the
sites are deployed on heroku, which means ssl is either really
expensive or really a pain.
In addition to the login details, i also pass user rolls
(authorization) to each site that is then stored in a session.
Any input is greatly appreciated.
The problem with this approach is that neither the sessionid (url or cookie) nor the exchanged data is encrypted. Therefore the data can be read and manipulated both on the way from the server to the user and on the way from the user to the server.
Even a passive attacker that can just sniff the traffic without being able to manipulate it, can create damage: The attacker can just copy the sessionid into his or her own browser. Public wireless connections often use a transparent proxy, so both the attacker and the victim have the same public ip-address, which makes it difficult for the application to tell them apart.
There is a tool called Firesheep that makes this kind of attack extremely easy.