Jump to content

Full SSL (HTTPS) support for the entire forum?


bjornk

Recommended Posts

Not sure if this has already been discussed before, but LL forum software doesn't seem to fully support secure connections (HTTPS) for its topics that are viewed from within an HTTPS connection. What I mean by that is, you can open a page on LL over HTTPS by adding an https:// in front of the address, however any forum link you click from within that page opens as a non-secure connection (HTTP).

 

From what I've read on the Invision community posts, full SSL support can be enabled by changing the board's URL. Is there a reason to keep it this way (as HTTP, I mean)? I think it would be nice to have full HTTPS support for the entire forum.

 

 

Link to comment

I'm sick to death of this "SSL/TLS everything" mentality. Not every bit between a webserver and your eyeballs merits encryption and the increased resources and costs such connections require. For crying out loud, youtube is fully HTTPS now and for what? Some bored sysadmin at my ISP might be peeking in on which videos I'm watching? All this does is add additional costs in bandwidth, processing, and memory at both ends. For a site like LL it also means paying the certificate mafia for a cert or else your browser is going to tell you the site is less secure than it thinks it is without any encryption at all!

Link to comment

You essentially answered your own question:

 

What I mean by that is, you can open a page on LL over HTTPS by adding an https:// in front of the address, however any forum link you click from within that page opens as a non-secure connection (HTTP).

The same is true when the opposites in effect. If SSL is enabled in the forum software, all the links on the page are https, regardless if you are trying to browse it from non-https.

 

"Who cares, they should be happy to browse it with https instead!" You might say, but it might cause compatibility issues for some users, the site ads don't display (though the ad publisher is supposedly adding SSL support soon/eventually), cause additional CPU strain and slower connection speeds (however slight that difference might be), and it's honestly just mostly completely unnecessary; unless you are stupidly entering your credit card number or other secure information somewhere on loverslab, there is no need for it.

 

The exception being your login info, when logging into LoversLab it posts your login info the https version of the site to validate before redirecting you back to the regular non-https - which is the sole reason I got an authority signed SSL cert for LoversLab and set it up to begin with.

Link to comment

I didn't even realize you have/had a cert. Even the credentials though, I question their need to be encrypted with a real cert, unless you're doing something nearly as stupid as entering your CC info here -- using the same user/pass that you use elsewhere.

 

Secure challenge/response for login can be implemented with a little javascript without any need for actual encryption or an SSL cert. SMF (simplemachines) supports this out of the box and has for almost ten years.

Link to comment

I didn't even realize you have/had a cert. Even the credentials though, I question their need to be encrypted with a real cert, unless you're doing something nearly as stupid as entering your CC info here -- using the same user/pass that you use elsewhere.

 

Secure challenge/response for login can be implemented with a little javascript without any need for actual encryption or an SSL cert. SMF (simplemachines) supports this out of the box and has for almost ten years.

 

It's pretty much a given that the majority of people use the same user/pass everywhere, and SSL is a much much more reliable method of securing a user's password during login than any anything as one-sided or front-facing as javascript, which would be useless against any local malware infections a user might have on their computer sniffing packets (without also including a MITM attack).

 

A signed cert is 10 dollars a year, an incredibly small price to pay to save some people from themselves or give some security paranoids a little piece of mind.

Link to comment

A JS challenge response isn't any more vulnerable to attack than the one SSL/TLS itself uses. A local sniffer won't get anything of value from either one, and hijacking the browser locally compromises both. It's just a different channel.

 

Certs have obviously come down in price though. I was going to say that RapidSSL was among the cheapest and they're still $50/yr, but you're using them and it was only $10?

Link to comment

Some might be concerned with their local government accessing their web traffic. In some countries it might even be illegal. Secure connection might be what they are asking about for that reason. (yes that don't really make sense but I have heard this before r/t this SSL issue)

 

Now if that is the case a Proxy would be the safest in my opinion.. (paid preferably and if concerned from another country where what is being viewed is legal) Then they can't see what is going on in your traffic when you enter here. Also local hackers have a harder time as it will likely be encrypted from your computer to the main proxy server which itself should be much harder to hack that connection. Finally anyone that desires to trace you.. only see the proxy you are using and not your home  IP. Much more secure (so far as I know) added level of protection which some security experts even advise however it will likely slow down your connection for this security.

Link to comment

A JS challenge response isn't any more vulnerable to attack than the one SSL/TLS itself uses. A local sniffer won't get anything of value from either one, and hijacking the browser locally compromises both. It's just a different channel.

Anything JS is going to be fully one sided to the potentially infected users machine, and anything JS does to encrypt a password before sending it to a login server, is completely reversible, the javascript is all there in readable format to see how encrypting before sending or what sort of response it's expecting back, a challenge/response from the login server before sending doesn't solve the problem either since the packet sending/receiving that could be manipulated and or just as easily by something malicious as the packet sending the password over non-ssl. Anything you put into a website via an regular HTTP GET/POST request (such as username and password), as well as the servers response, are all equally visible to any spyware sniffing your outgoing/incoming tcp packets in full plaintext, usually as "username=myusernamehere&password=mypasswordhere" no less.

 

This is the precise reason Lenovo's very recent "Superfish" debacle was such a big deal.

 

Certs have obviously come down in price though. I was going to say that RapidSSL was among the cheapest and they're still $50/yr, but you're using them and it was only $10?

Yup, and RapidSSL wasn't even the cheapest one: https://www.namecheap.com/security/ssl-certificates/domain-validation.aspx

 

They only get expensive once you start wanting multiple domains or subdomains on a single cert, or have a reason to buy into the "super trustworthy" cert authorities like VeriSign.

Link to comment

 

A JS challenge response isn't any more vulnerable to attack than the one SSL/TLS itself uses. A local sniffer won't get anything of value from either one, and hijacking the browser locally compromises both. It's just a different channel.

Anything JS is going to be fully one sided to the potentially infected users machine, and anything JS does to encrypt a password before sending it to a login server, is completely reversible, the javascript is all there in readable format to see how encrypting before sending or what sort of response it's expecting back, a challenge/response from the login server before sending doesn't solve the problem either since the packet sending/receiving that could be manipulated and or just as easily by something malicious as the packet sending the password over non-ssl. Anything you put into a website via an regular HTTP GET/POST request (such as username and password), as well as the servers response, are all equally visible to any spyware sniffing your outgoing/incoming tcp packets in full plaintext, usually as "username=myusernamehere&password=mypasswordhere" no less.

 

My point is that a properly implemented challenge response with a JS client is only susceptible to the same attacks as TLS itself. Through pure wire sniffing, it is no more reversible than the TLS handshake itself is.

 

An example exchange (kerberos):

1. Client transmits username in the clear.

2. Server uses password hash to encrypt a random number and sends it to client.

3. Client uses password hash to decrypt the number, adds one, encrypts the result, and sends it back.

4. Server decrypts and verifies.

 

You can add a 5th step where the server adds one again, encrypts, and sends to the client. This allows the client to also verify that the server knows the password hash.

 

The same data is available through sniffing regardless of the client used. This is not vulnerable to a 'normal' man in the middle attack, which is a 3rd device sitting between the client and server, attempting to impersonate each side.

 

It is vulnerable to the client OS or browser being hijacked (as happened with superfish) but so is TLS itself -- that's exactly what superfish does. Hijacks SSL connections by installing it's own self-signed CA into the trusted local store.

 

 

 

Certs have obviously come down in price though. I was going to say that RapidSSL was among the cheapest and they're still $50/yr, but you're using them and it was only $10?

Yup, and RapidSSL wasn't even the cheapest one: https://www.namecheap.com/security/ssl-certificates/domain-validation.aspx

 

They only get expensive once you start wanting multiple domains or subdomains on a single cert, or have a reason to buy into the "super trustworthy" cert authorities like VeriSign.

 

I can't find any rapidssl that's that cheap. The one year if bought from their clickvertised site (rapidsslonline) is $18, if you buy three years at once it's $13. Still less than the $50/yr on the main site though. I like them, have used in the past for normal and wildcard.

Link to comment

Some bored sysadmin at my ISP might be peeking in on which videos I'm watching?

Governments do that kind of thing these days, instead of sysadmins. Either to profile you or to block your access to what they deem dangerous or illegal.

 

Also, you might want to rethink your attitude towards HTTPS, as some ISPs inject ads into unencrypted connections, some even attempt to steal user passwords.

 

http://arstechnica.com/tech-policy/2013/04/how-a-banner-ad-for-hs-ok/

 

http://www.theatlantic.com/technology/archive/2011/01/the-inside-story-of-how-facebook-responded-to-tunisian-hacks/70044/

 

To me, costly or not, secure connection is definitely a better alternative.

 

Now if that is the case a Proxy would be the safest in my opinion.. (paid preferably and if concerned from another country where what is being viewed is legal) Then they can't see what is going on in your traffic when you enter here. Also local hackers have a harder time as it will likely be encrypted from your computer to the main proxy server which itself should be much harder to hack that connection. Finally anyone that desires to trace you.. only see the proxy you are using and not your home  IP. Much more secure (so far as I know) added level of protection which some security experts even advise however it will likely slow down your connection for this security.

A proxy server is not a safe solution at all. All it may do is to allow you access to some websites that are blocked in your country and it may also hide your real IP, if it isn't a transparent one. But the truth is, they may easily be used to track your online activities. It's even possible that you have already been subjected to a transparent proxy without your consent or knowledge, as some ISPs do use those. Also in some countries DPI (Deep Packet Inspection) is used to analyze your Internet traffic, so using a proxy over an unencrypted connection won't do you any good in that case.

 

Using a strong VPN connection is a better alternative but in some countries you can't even use common VPN protocols as the ports they use are blocked. OpenVPN might work, but the Softether which uses HTTPS is a better alternative as they can't block HTTPS traffic.

 

VPS is another solution if you want to set up your own VPN (or proxy) server.

 

In each of these cases though, you must use a reliable VPN/VPS/Proxy provider.

Link to comment

Yes a fully encrypted proxy server from a reliable service would be the way to go. There are many to choose from. Not to good if you are trying something illegal as they can and will have your logs and depending on their information gathering and retention practices they might have them for some time. There is even some that stated that they help prevent the deep packet inspection as well. haven't checked into how viable that is and not sure if it is end to end protection or just from the VPN service to your home.

 

Truth is like you sort of pointed out.. it is almost impossible to prevent someone from hacking your connection if they have intent. All that can be done is make it harder for them to detect and hack. In this web sites case. Ashal protects the log on but not the rest as he don't want to add stress to the system and slow things down for many people.

Link to comment

 

Some bored sysadmin at my ISP might be peeking in on which videos I'm watching?

Governments do that kind of thing these days, instead of sysadmins. Either to profile you or to block your access to what they deem dangerous or illegal.

 

To profile me? I doubt it. To block my access to subversive sites? They can do that with or without an encrypted connection, if you aren't using a proxy of some kid.

 

Also, you might want to rethink your attitude towards HTTPS, as some ISPs inject ads into unencrypted connections, some even attempt to steal user passwords.

My attitude towards SSL/TLS is unchanged. It's a sledgehammer to pound in a finishing nail in both of these cases. You also may want to read the articles you link more closely.

 

ISPs can force a downgrade of https to http

This is terribly easy to do. If the ISP acting on their own or on behalf of some agent like a government wants to sniff your traffic, they'll do so -- or more likely, they will use their own cert to fool you into thinking that your traffic is secure when it isn't.

 

To me, costly or not, secure connection is definitely a better alternative.

This is often the attitude of the people that want a thing, don't fully understand the thing, and don't have to pay for the thing. SSL/TLS takes more CPU and memory resources, more network traffic (in some cases, much more, since encrypted traffic is incompressible by definition), and the certs cost money.

 

Then, at the end of the day, it's not offering you the protection you think it is. All of your HTTPS traffic could be going to a spy box in the middle that's using a legitimate cert before being decrypted, logged, and then sent on to its destination. You'd never know it was happening unless you compared the cert to one retrieved from a known safe path.

Link to comment

To profile me? I doubt it.

If they have the capability, I'm sure they'd profile everyone.

 

To block my access to subversive sites? They can do that with or without an encrypted connection, if you aren't using a proxy of some kid.

It would be more difficult to tamper with the content you get through an encrypted connection, that's what I meant. The two articles linked above are a proof of this.

 

they will use their own cert to fool you into thinking that your traffic is secure when it isn't.

All of your HTTPS traffic could be going to a spy box in the middle that's using a legitimate cert before being decrypted, logged, and then sent on to its destination. You'd never know it was happening unless you compared the cert to one retrieved from a known safe path.

Well, yes, but at least you'd know that your connection is being intercepted by comparing fingerprints of the original certificate to the ones you get in your browser. They'd probably have to temper with the certificate authorities defined on my system as well to be able to do such a thing.

Link to comment

 

To profile me? I doubt it.

If they have the capability, I'm sure they'd profile everyone.

 

I guess I'd have to understand what you mean when you say "profiling" in that case, but I'm wary of asking because my tinfoilometer is starting to beep.

 

It would be more difficult to tamper with the content you get through an encrypted connection, that's what I meant. The two articles linked above are a proof of this.

For a state level actor that isn't a dirt poor banana republic (i.e. a modern western nation)? It's not any more difficult at all. In any case you did say blocking before, not tampering. Tampering is easily detected by just signing the content, no need to encrypt all of it.

 

Well, yes, but at least you'd know that your connection is being intercepted by comparing fingerprints of the original certificate to the ones you get in your browser. They'd probably have to temper with the certificate authorities defined on my system as well to be able to do such a thing.

You'd only know that if you had a secure channel to get that fingerprint in the first place, and had the technical knowhow. For the average person concerned with this kind if thing, neither of those is true. Tampering with the secure store is something they'd have to do, you're right, and that's exactly what happened with the Lenovo/superfish thing.

 

I'm not saying, and haven't said, that encryption is pointless. I have said, and continue to say, that it's very situational. It's certainly pointless to encrypt all traffic between myself and youtube, or between myself an LL, or between myself and just about any non-shopping non-'subversive' site. This is different for people in other countries perhaps.

 

So those people should have the option to use HTTPS, and by and large, they do. Asking that every site be encrypted all the time is a complete waste of time, money, and energy for no benefit to the majority of people or sites.

Link to comment

I guess I'd have to understand what you mean when you say "profiling" in that case, but I'm wary of asking because my tinfoilometer is starting to beep.

In some countries, your credit card number is the least important thing to worry about when posting something over the net. From your political views to your sexual preferences, everything about you has a value, and can be used against you. Some governments even pass laws to be able to legally store that kind of data.

 

In any case you did say blocking before, not tampering. Tampering is easily detected by just signing the content, no need to encrypt all of it.

You can't sign dynamic web content. If they are able to tamper with the content coming towards you they can easily add, delete or change anything they want. Ad injection is just one example. They can easily change or delete a word, a name or a URL from the content you receive. That's how they'd "block" the content they don't wish you to view. It's not a viable solution for them though, because of the increasing use of HTTPS.

 

You'd only know that if you had a secure channel to get that fingerprint in the first place, and had the technical knowhow. For the average person concerned with this kind if thing, neither of those is true.

I don't think it'd be that difficult to find out. You can use something like this to verify certificate fingerprints.

Link to comment

 

Yes you can.

How?

 

What do you mean? It's no more difficult than signing static content. Capture/tee the output as you're sending it, when it's sent, calculate the signature and send that as well. If you want the signature in an HTTP header you have to buffer the output first since you have to send headers before content, but that's no problem.

 

 

Using the same insecure channel that may already be compromised?

That's the purpose of that page.

 

My point is you can't guarantee you're reaching that page instead of an imposter if your channel (network connection, browser, etc) is the thing you suspect of being compromised.

Link to comment

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. For more information, see our Privacy Policy & Terms of Use