Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Actually my only requirement for using SSL encryption is that when a user logs in, the password is transferred encrypted. However after reading a bit about protocol switching, that an HTTPS session can't be taken over as an HTTP session etc. I've been asking myself if it's so bad to just have the entire application use HTTPS only.

What are the reasons against it and how would you rate their importance? Please also mention:

  • How much performance do I lose on server side (roughly)?
  • How much performance do I lose on client side (roughly)?
  • Any other problems on server / client side?
share|improve this question

3 Answers 3

Reasons against: none. Internet is insecure network and must be treated as such.
About performance:
if your performance target is not < 500 ms response in 99% time, SSL is not bottleneck for you.Most time, there are a lot more beneficial performance improvements available than turning of SSL.

Biggest performance clog for HTTPS ir handshake, but you can migate it by:
- turning on keepalive
- enabling TLS session resumption, which ammortizes cost of assimetric cryptography, without session resumption client on every request sends certificate (few kb/s) and server has to do RSA decryption ...

For improving client/server side performance, it is more important to reduce number of requests/responses/compress content .. etc.

If your server and client software is not horribly outdated, there should be no problems with SSL, excluding certificate/trust chain installation on server and renewing certificate ...

Rememeber that 99% percent of web apps are I/O, not CPU bound, so SSL will be just using otherwise idle server CPU cycles.

share|improve this answer
    
Absolutely agree with this. If performance is a concern with SSL enabled, this should be addressed in other ways, not by compromising the security of user data. –  RobM Nov 11 '10 at 13:28
    
@Robert The alternative to using https on the entire site would be protocol switching to http after confidential data like the password has been entered. This would make it more complicated to program, but not compromising the security of user data. –  Joe Nov 12 '10 at 7:29
    
@user54455 - I understand that but I'm thinking of any data that might be stored on the app, not just login credentials. I don't know what your app does, obviously, but if, for example, its an online CRM tool and a company I buy from was using it, I would not feel reassured to know that my sales rep's password was encrypted but my sales history as their customer was not. –  RobM Nov 12 '10 at 9:22

You don't state which authentication method you're using. If you're using Basic auth, then bear in mind that the credentials are sent with every request until the browser is closed. anyway, so there's no point switching down.

With any SSL connection, the only performance-heavy aspect is the initial handshaking for the connection. Once the client and server have exchanged keys, the overhead is negligible on both the client and the server, so there's no real harm in continuing the SSL connection, unless you're dealing with a seriously high-volume server. What kind of load are you expecting?

share|improve this answer
    
I'm not too familiar with basic auth etc. I just know that when logging in, the user and password are transmitted using the POST method and that the session information is stored inside a cookie. How do you call this? Regarding the volume, I don't expect extreme loads and I don't have extreme requirements regarding performance, so based on the answers I guess SSL will be ok for my entire website. –  Joe Nov 11 '10 at 16:59
    
Indeed. If performance is not a concern, then just stick with SSL the whole way. Looking at your response to Robert, above, bear in mind that when the auth is handled by the application, it's then the session cookie, not the user:password information that is cached by the browser and sent with every request. It's still interceptable, but the increased security comes from the fact that the session cookie will expire after a short time (hopefully) and become useless to an attacker, so the time window is much reduced. –  SmallClanger Nov 12 '10 at 9:43

Agree wih SmallClanger and Kristaps.

I have no numbers concerning the performance impact, but I'd go full SSL (keyword Firesheep). I know that such attacking techniques exist for years, but awareness is incresing right now and the only real solution is full SSL.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.