Tls

Status
Not open for further replies.

agrieco

New User
anthony
Have the folks that run the site considered enabling TLS (ie encryption) for the site? From the looks of it, there is a certificate issued and the HTTPS version of the site simply redirects to non-HTTPS.

Why? Most humans stink at password management (particularly password reuse). I'd hate for someone to have their credentials stolen from here and that + profile information to start looking around other places. Certainly TLS doesn't solve that completely, but does help thwart common mobile attacks (think starbucks wifi).

I'm happy to help if this is a person-power or technical experience issue.

thanks for all you do
anthony
 

FlyingRon

Board of Directors, Webmaster
Ron
Staff member
Corporate Member
Alas, vBulletin 4, the software used by this forum, does not support SSL/TLS so it's not just an issue of "turning it on".

Even small upgrades to vBulletin are perilous. Upgrading to vB 5 has been on the list since before I took over as webmaster four+ years ago. We'll get there eventually.
 

ehpoole

Administrator
Ethan
Actually, this site switches back and forth between HTTP and HTTPS depending upon the sensitivity of various areas. It is not a perfect setup at this point in time because the built-in nature of vBulletin is an all-or-nothing deal, so there are a lot of server side rewrite rules coupled with custom plugin code to achieve this middle ground.

About the only sensitive thing not presently encrypted (and which I will likely address at some point) is the actual login process. However, your actual password is never really exchanged during login as vBulletin uses a challenge-response method for login, so the two sides are trading hashes that change with each login and it is those changing hashes that actually get transmitted during the login process (provided JavaScript has not been disabled).

However, if you venture to other sensitive areas such as "Private Messages" or editing your profile and other areas where sensitive personal information may typically be exchanged you will find that those areas switch to HTTPS (SSL) encryption to protect your privacy. What we do not bother encrypting are the public areas as they display nothing that is not already available to the general public, so there is nothing particularly sensitive about these areas.

That said, we do not support TLS (where both HTTP and HTTPS reside on the same port), rather we use the traditional SSL strategy of dedicated ports for each, where port 80 is unencrypted traffic and port 443 is SSL encrypted traffic.

Because of the way vBulletin works, if we were to try and encrypt everything then we would have to effectively deny all non-encrypted connections because vBulletin would either by turning HTTPS on at every step or it would be turning it off at every step. To implement the middle ground we currently have takes a good deal of behind the scenes magic to make happen. Part of the argument against encrypting absolutely everything is the increased load on the server and the added latency inherent to SSL connections (which is considerable compared to non-SSL connections). Under normal circumstances our new server could handle the routine load, but it could potentially be brought down (or otherwise refuse further connections) by a poorly implemented spider hitting the server with many thousands of concurrent SSL requests (and there are some very poorly implemented spiders out there), so we have opted for a middle ground that affords greater reliability when faced with such stress while still protecting many of the more sensitive areas. The most critical areas, such as management control panels are 100% encrypted along with additional protections as those are the most sensitive of all areas.
 

Gotcha6

Dennis
Corporate Member
Actually, this site switches back and forth between HTTP and HTTPS depending upon the sensitivity of various areas. It is not a perfect setup at this point in time because the built-in nature of vBulletin is an all-or-nothing deal, so there are a lot of server side rewrite rules coupled with custom plugin code to achieve this middle ground.

About the only sensitive thing not presently encrypted (and which I will likely address at some point) is the actual login process. However, your actual password is never really exchanged during login as vBulletin uses a challenge-response method for login, so the two sides are trading hashes that change with each login and it is those changing hashes that actually get transmitted during the login process (provided JavaScript has not been disabled).

However, if you venture to other sensitive areas such as "Private Messages" or editing your profile and other areas where sensitive personal information may typically be exchanged you will find that those areas switch to HTTPS (SSL) encryption to protect your privacy. What we do not bother encrypting are the public areas as they display nothing that is not already available to the general public, so there is nothing particularly sensitive about these areas.

That said, we do not support TLS (where both HTTP and HTTPS reside on the same port), rather we use the traditional SSL strategy of dedicated ports for each, where port 80 is unencrypted traffic and port 443 is SSL encrypted traffic.

Because of the way vBulletin works, if we were to try and encrypt everything then we would have to effectively deny all non-encrypted connections because vBulletin would either by turning HTTPS on at every step or it would be turning it off at every step. To implement the middle ground we currently have takes a good deal of behind the scenes magic to make happen. Part of the argument against encrypting absolutely everything is the increased load on the server and the added latency inherent to SSL connections (which is considerable compared to non-SSL connections). Under normal circumstances our new server could handle the routine load, but it could potentially be brought down (or otherwise refuse further connections) by a poorly implemented spider hitting the server with many thousands of concurrent SSL requests (and there are some very poorly implemented spiders out there), so we have opted for a middle ground that affords greater reliability when faced with such stress while still protecting many of the more sensitive areas. The most critical areas, such as management control panels are 100% encrypted along with additional protections as those are the most sensitive of all areas.

What he said...... :icon_thum
 

agrieco

New User
anthony
Actually, this site switches back and forth between HTTP and HTTPS depending upon the sensitivity of various areas. It is not a perfect setup at this point in time because the built-in nature of vBulletin is an all-or-nothing deal, so there are a lot of server side rewrite rules coupled with custom plugin code to achieve this middle ground.

About the only sensitive thing not presently encrypted (and which I will likely address at some point) is the actual login process. However, your actual password is never really exchanged during login as vBulletin uses a challenge-response method for login, so the two sides are trading hashes that change with each login and it is those changing hashes that actually get transmitted during the login process (provided JavaScript has not been disabled).

However, if you venture to other sensitive areas such as "Private Messages" or editing your profile and other areas where sensitive personal information may typically be exchanged you will find that those areas switch to HTTPS (SSL) encryption to protect your privacy. What we do not bother encrypting are the public areas as they display nothing that is not already available to the general public, so there is nothing particularly sensitive about these areas.

That said, we do not support TLS (where both HTTP and HTTPS reside on the same port), rather we use the traditional SSL strategy of dedicated ports for each, where port 80 is unencrypted traffic and port 443 is SSL encrypted traffic.

Because of the way vBulletin works, if we were to try and encrypt everything then we would have to effectively deny all non-encrypted connections because vBulletin would either by turning HTTPS on at every step or it would be turning it off at every step. To implement the middle ground we currently have takes a good deal of behind the scenes magic to make happen. Part of the argument against encrypting absolutely everything is the increased load on the server and the added latency inherent to SSL connections (which is considerable compared to non-SSL connections). Under normal circumstances our new server could handle the routine load, but it could potentially be brought down (or otherwise refuse further connections) by a poorly implemented spider hitting the server with many thousands of concurrent SSL requests (and there are some very poorly implemented spiders out there), so we have opted for a middle ground that affords greater reliability when faced with such stress while still protecting many of the more sensitive areas. The most critical areas, such as management control panels are 100% encrypted along with additional protections as those are the most sensitive of all areas.
Thanks for the detailed response. I better understand the situation and appreciate the complexity of the situation (security's failing as an industry). Prior to my post, the place I had checked specifically was the login form. I saw the client side md5hash- I'm afraid an unstalted hash doesn't provide a ton of protection (rainbow tables and all)....but it sounds like you're already there.

There are some neat tricks you can play with nginx (ssl-offload/reverse proxy) or a free tier of Cloudflare that might help if you all were interested. Sounds like you're pro's while not making sawdust...so I'll leave it in your capable hands- just let me know if I can help at all.

anthony
 
Status
Not open for further replies.

Our Sponsors

LATEST FOR SALE LISTINGS

Top