1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

SSL Overheads?

Discussion in 'Internet, Connectivity and Communications' started by garyb, May 8, 2008.

  1. garyb

    garyb Byte Poster

    I have several business sites all using SSLs from login screen down so all my sites are secured on 443. I am noticing some lag in the site on occasions which causes errors with .NET, we dont partuclary have high hits on the site but I guess the data side is quite hard. I am thinking of retaining the login page as SSL but after that dropping it to normal http to see if that will ease the overheads. Has anyone done this before, does it help? Also are there any serious security implications, we are regulated by FSA so have to be careful with data security..

    WIP: MCSA 2003
  2. dmarsh

    dmarsh Terabyte Poster

    SSL should be used for all pages that contain sensitive information to protect from sniffing, this mainly includes pages with forms but could also include other pages if you have reports or other sensitive information. If its an intranet site or the information is not massively sensitive then you can just rely on the initial authorisation as you infer and take the risk of your packets getting captured.

    You could consider SSL offload to another device or other tuning of your application, its not clear that SSL is the issue, it might be other parts of your infrastructure or the design of the app.
    Certifications: CITP, BSc, HND, SCJP, SCJD, SCWCD, SCBCD, SCEA, N+, Sec+, Proj+, Server+, Linux+, MCTS, MCPD, MCSA, MCITP, CCDH
  3. garyb

    garyb Byte Poster

    Hi & thanx for the reply.
    I know the risks are high but I have been left with online apps developed by people with no regard to bandwidth or end user experience.. This is most noticeable with Ajax code when a user moves through the page quickly, the code cant catch up due to bandwidth limits [their end or mine], and eventually errors, not nice looking..

    I do know the SSL is at least partly responsible, as our "pre-live" enviroment has no SSL and much better response times and very little errors, hence the reason I was thinking of implementing this in live servers. Another factor would be the hardware firewall with IDS/IPS and Gateway AV but the "pre-live" is behind this too..

    WIP: MCSA 2003
  4. hbroomhall

    hbroomhall Petabyte Poster Gold Member

    I would say that it would be a somewhat underpowered machine that would be slowed noticeably by the encryption stuff.

    And pre-live systems are often faster because the database is small and can be cached. Once it starts to grow then you hit the disk more often.

    You could try more memory in there?

    Certifications: ECDL A+ Network+ i-Net+
    WIP: Server+

Share This Page