Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

HTTPS SSL support

This site may earn commission on affiliate links.

mpt

Electrics are back
Supporting Member
I've added an SSL certificate to the site but need to test it out this weekend.

Anyone any thoughts on the use of SSL on the site? My reason for testing would be to add encryption of the userid and password plus, when reading the site it will be encrypted and free from eaves dropping.
 
works on FF 4.0.1 , but doesn't show "it's safe" cause the validation is missing .... i thing ..

As far as I can tell it's because the JavaScript used on the site is loaded from a "non-secure" (non-HTTPS) location.

Here's the full bit off Chrome:
Your connection to Tesla Motors Club - Enthusiasts & Owners Forum is encrypted with 128-bit encryption. However, this page includes other resources which are not secure. These resources can be viewed by others while in transit, and can be modified by an attacker to change the behavior of the page.

Before getting that message Chrome says something like "The page contains a non-secure script, are you sure you want to load it anyway?".
 
Is it really needed? Who cares if someone snoops on a public forum?
And it doesn't seem like anything sensitive enough goes on here where a password needs to be heavily protected.
 
Many sites are moving towards having everything be HTTPS (e.g. Twitter: Twitter enables always-on SSL encryption - Faster Forward - The Washington Post and Facebook: Incompatible Browser | Facebook) so you don't need to worry about switching back and forth. Even the js and images are returned via HTTPS. Honestly, I didn't realize the login form didn't use HTTPS (although it looks like you are doing a hash function in JS so aren't sending the passwords in clear text).

TEG, there are 2 main reasons you want security:
1. Some people may be using the same password on this site as other sites. So if I can steal your password on this site, perhaps I can log in to your email.
2. If I steal your password, I can use the fact that you are a trusted user and PM random people and probably get them to give me useful information such as their real names or addresses.

mpt, be grateful you aren't doing anything with credit cards or you would have to follow PCI rules which is a ton of fun...
 
Many sites are moving towards having everything be HTTPS (e.g. Twitter: Twitter enables always-on SSL encryption - Faster Forward - The Washington Post and Facebook: Incompatible Browser | Facebook) so you don't need to worry about switching back and forth. Even the js and images are returned via HTTPS. Honestly, I didn't realize the login form didn't use HTTPS (although it looks like you are doing a hash function in JS so aren't sending the passwords in clear text).

TEG, there are 2 main reasons you want security:
1. Some people may be using the same password on this site as other sites. So if I can steal your password on this site, perhaps I can log in to your email.
2. If I steal your password, I can use the fact that you are a trusted user and PM random people and probably get them to give me useful information such as their real names or addresses.

mpt, be grateful you aren't doing anything with credit cards or you would have to follow PCI rules which is a ton of fun...

Bingo. Because people tend to use the same password everywhere, capturing a password here could expose your bank account. But vBullrtin encrypts the password before sending it, so SSL is not necessary for password protection.

Assuming you still want to use the certificate, one issue you are having right now is that the site uses HTTPS, but vBulletin doesn't know this so it sends much of the content as HTTP links. For instance, the stylesheet is referenced as http://whatever, so the browser sees encrypted and unencrypted content. I haven't used vBulletin in while, but I seem to recall there's an administrative setting somewhere. Or, it might be a problem with PHP misreporting the protocol because of some server settings (although I've had no trouble with GoDaddy hosting in this regard).

Another (non)issue is that the site says (in Firefox) "Verified By: Not Verified". People often think this is a problem, but it wouldn't be here. A certificate provides two things (1) encryption and (2) authentication of the site. Less expensive certificates are not verified to ensure the site buying the certificate is really the site they say they are. It's necessary, for instance, for a bank to prove that their site really is their site. Here, not so much. So a bank will pay the extra bucks to have third-party verification, but TMC shouldn't waste the effort.
 
And you have to stay on top of certificate expirations and renewals...

Would the certificate work for both http: //teslamotorsclub.com http: //www.teslamotorsclub.com?
Sometimes sites that have both www and without have trouble with the certificate only being for one.
(Maybe you would need to have one redirect to the other.)
 
And you have to stay on top of certificate expirations and renewals...

Would the certificate work for both http: //teslamotorsclub.com http: //www.teslamotorsclub.com?
Sometimes sites that have both www and without have trouble with the certificate only being for one.
(Maybe you would need to have one redirect to the other.)
Yes and yes. I'm with you on this one TEG. I see no reason to go through the time and expense to to encrypt the site.
 
Despite serious misgivings about the certificate authority "cartel" and the marginalization of self-signed certificates they've been able to encourage in all browsers (even open source), SSL/HTTPS is the widely used option for encryption of HTTP content. So for the time being, I applaud and welcome the effort even if I also agree that nothing we're doing here is especially sensitive and I personally use unique passwords at every site.

It generally doesn't hurt to be cautious. And use of HTTPS, once available and configured properly, is painless for the user.

That said, unless the problems others have cited can be addressed, the effort is unfortunately in vain. Most notably, using absolute and insecure URLs for the assets (CSS, JavaScript, etc.) causes the session cookie to be sent to the server in the clear. Therefore session hijacking, which is probably the most common form of HTTP attack, remains trivial to anyone who is acting as a man in the middle (e.g. monitoring traffic within a Starbucks, assuming the client doesn't connect to a VPN).

If possible, relative URLs should be used for assets so that content requests made from an HTTPS session retain the use of HTTPS to fetch assets.

I've also noticed that absolute URLs are used for all site navigation, meaning that if I visit the home page using HTTPS, the links to forums and threads leave HTTPS. I'm guessing this is because you're still experimenting with the idea, but to be clear, all navigation should also use relative links so that the user doesn't unwittingly exit HTTPS.

Also important is that users should initiate their session using HTTPS. Otherwise, unless the server is configured to disallow the creation of a session (and therefore delivery of a session cookie) over HTTP, the session will still be vulnerable to hijacking. Another option is to configure the server to deliver a new session cookie when SSL is enabled. Many sites inappropriately deliver a session cookie when displaying a home or other welcome page and then switch to HTTPS only when the user navigates to the "login" page. Unfortunately, the session cookie is often left unchanged, so any man in the middle who captured the initial request can still hijack the session.
 
works on FF 4.0.1 , but doesn't show "it's safe" cause the validation is missing .... i thing ..

Just to be clear, I've not enabled/forced it yet, I've just added the SSL cert to the site. vB, as howabout2 spotted includes the protocol in the generated URLs so to do https properly I'll have to include the protocol in the site url; should all be relative but there you go; I'll try it to see if that's possible.