HTTPS for EEVBlog Forums?

[Bud]

Thank you very much for the recommendation which i am not going to take because i know this. I was simply pointing to technical possibility of SSL decryption between a source and its ultimate destination, without going into details of the actual methods used. You do not specifically "direct" your traffic to the proxy when you type https://whatever.com in the browser and that is all that matters for the purpose of this discussion.

[Cerebus]

https doesnt hide your source and destination and port. Pretty sure someone sniffing you would know whats important and not important. Is eevblog as important as your email, cloud services and online banking?

A further point on this. Eevblog is actually distributed by the Cloudflare content distribution system. If you were using HTTPS to connect, someone sniffing your traffic would only be able to see that you were connecting to Cloudflare. They would not be able to see which of Cloudflare's 2,000,000 customer sites you were actually connecting to. The statistics are probably worse than that in that Cloudflare use IP address pools but an individual website will only use one of those IP addresses so the detection odds shorten to 1 in a few thousand, but that's still very useful in minimizing the usefulness of traffic analysis. It does however introduce Cloudflare as a trusted third party because of the way they work HTTPS, which is not so good.

[Kjelt]

Thank you very much for the recommendation which i am not going to take because i know this. I was simply pointing to technical possibility of SSL decryption between a source and its ultimate destination, without going into details of the actual methods used. You do not specifically "direct" your traffic to the proxy when you type https://whatever.com in the browser and that is all that matters for the purpose of this discussion.

Your technical possibility assumes a lot of things that are not very relevant for the discussion either.
If you have a hard URL that DNS servers around the world can resolve there is no way some malicious 3rd party can intercept that with a proxy without you knowing it just by looking at the certificate and the url you are connected to. If you think that is possible show some proof cause and present it on defcon or blackhat and be famous.

[Kjelt]

To further elaborate on this you can only hijack traffic from Alice(you the client) to Bob (server) and get away with it if you perform one of the following:
WPAD hijacking, DNS hijacking, DNS cache poisoning or a BGP route hijack and then you need a valid CA signed certificate for Bob that Alice will accept and you need Bobs private key.
Which means you have succesfully hacked a CA like Diginotar in the past or have hacked Bob and obtained its private key. Any other case you know you are not dealing with Bob OR you can not decipher the code.

But this is to my knowledge, please share your solution.

[madires]

Thank you very much for the recommendation which i am not going to take because i know this. I was simply pointing to technical possibility of SSL decryption between a source and its ultimate destination, without going into details of the actual methods used. You do not specifically "direct" your traffic to the proxy when you type https://whatever.com in the browser and that is all that matters for the purpose of this discussion.

If you know the basics, why are you still claiming that a proxy can decrypt a proper end-to-end TLS connection? And of course, the technical details matter. Also of course, you don't add the proxy to your browser's settings, it's a transparent proxy. And if you check the certificate, you'll see it's a fake one from the proxy. So you know you can't trust the connection. This is one of the important features of TLS and certificates.

Just for clarification: A proxy can impersonate a server successfully, when you are able to retrieve the keys from the server.

[Kjelt]

Just for clarification: A proxy can impersonate a server successfully, when you are able to retrieve the keys from the server.

Or as I already said have a "valid" certificate and private key for that specific server that the clients browser will accept, which in practice means a CA was hacked.
Not impossible but so rare it is very unlikely and in both cases the security was already broken.

[KE5FX]

I'll never ever understand the apathetic mindset shown towards privacy in this thread, and the blasé attitude towards the opportunity of using secure means of communication when it's available. If the tech is there, and IF it is not too much of a hurdle of actually using it, then use it! (Just to be clear, I'm not having a jab at you Dave... if there is a technical barrier in getting TSL happening, then so be it.)

Whether you have nothing to hide is immaterial and is a red herring argument. Everyone has something to hide, even when posting on a public arena, such as this forum. Most of the time you don't know what info posted under your pseudonym is valuable until you actually get doxed. When you get attributed to those discussions, often in a deliberately damaging way and out of context, you will feel the pain. Curious, how many of would you be comfortable allowing your potential employer read the comments you made here? I'm willing to bet that sizeable number of people would not want that.

The idea behind the Web was that there wouldn't be any "hurdles" at all.  No hurdles, and no gatekeepers, and that includes SSL vendors and certificate authorities.  If I want to serve a page consisting of nothing but <html><body>Hello, world!</body></html>, I should be able to do that with 20 lines of C code.  If I want to run a multibillion dollar e-commerce site, I should be able to do that with nothing more than a few more lines. 

This principle was, and is, important.  Far more important than any outdated (and grievously mistaken) notion of "privacy" that some people seem to expect when they hook up a network cable to their computer and start typing stuff.

Does that mean that it's a good idea to run an insecure e-commerce site?  Of course not.  But it was certainly a good idea to make it possible to publish information without asking anyone else's permission.  Everything beyond that is rightfully the server owner's call, and no one else's.

[AntiProtonBoy]

The idea behind the web is to connect people. How they communicate is their prerogative, whether it'd be plaintext or an encrypted stream.

[AntiProtonBoy]

https://www.eevblog.com/forum/

Forbidden

You don't have permission to access /forum/ on this server.
Server unable to read htaccess file, denying access to be safe

Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request.

It's happening?

[System Error Message]

why stop at https? lets use vpns and proxies too for everything.

[EEVblog]

It's happening?

Nothing to see here, move along now.

[orin]

Use of HTTPS does not protect against those type of attacks at all and if people use the same ids/passwords for a BBS site (or any non-encrypted authentication mechanism) as they do for more important sites (eg. online banking) then shame on them...

Such an attack would require:
- a way to intercept the traffic for a MITM
- a valid fake certificate from a CA or a way to push the root cert of a fake CA to the client
- a web browser with a poor visual indication of the trustworthiness of a certificate
- an user not checking the certificate

With http it would be just intercepting the traffic, like some ISPs/carriers do for inserting ads.

BTW, there are boxes for the https MITM, which are used in corporate environments, but require the fake root cert being pushed to the clients, i.e. via AD. They can be detected by checking the certificate.

It should be clear that you don't get 100% security by any encryption protocol. The goal is to make it harder for attackers. Even just being able to detect if someone it tampering with your IP traffic is a huge benefit.

Do seriously believe that the CA's Verisign etc haven't given away the keys to Gov ?  :

Perhaps they have.

But it's still not an argument against using TLS/SSL.  IF the CAs have given the government their private keys, then the government could mount a successful attack against end to end TLS/SSL.  Though why a government would bother to do so to get publicly available information beats me.

The argument I see so far is that 'someone' can break TLS/SSL so there is no need to use it.  I equate that argument to:

"One shouldn't bother to lock one's front door as 'someone' with a decent set of lock picks can get in."

You can never be 100% secure - whatever OS you use for your web server, your router or your client, open source or not.  (And IMO, the number of security flaws found in an OS is proportional to the number of hackers looking for them which in turn is proportional to the number of users of the OS in question.  In other words, at the moment, Windows is a more lucrative target for hackers due to the sheer number of Windows systems out there.)

[apelly]

why stop at https? lets use vpns and proxies too for everything.

I know, right?

But then again, just because we're ignorant, curmudgeonly security luddites doesn't mean everyone else is, hey?

[Jeroen3]

It's time.
Chrome started doing warning icons.

[Halcyon]

I'm sure Dave and Gnif are trying. But I will say this, privacy should be an option for those who want it rather than being left without a choice.

[AntiProtonBoy]

Depending on how the server is configured, one can have both options.

[Bud]

It's time.
Chrome started doing warning icons.

It is not because Chrome wants https, it is because a few things on the page cause rendering errors, one of which is the bloody Tapatalk. The Detail button gives exactly the details what is wrong.

[RGB255_0_0]

It's time.
Chrome started doing warning icons.

It is not because Chrome wants https, it is because a few things on the page cause rendering errors, one of which is the bloody Tapatalk. The Detail button gives exactly the details what is wrong.

Nope. Refers to the connection. All non-HTTPS sites have the exclamation mark.

[TheBay]

It's time.
Chrome started doing warning icons.

It is not because Chrome wants https, it is because a few things on the page cause rendering errors, one of which is the bloody Tapatalk. The Detail button gives exactly the details what is wrong.

Nope. Refers to the connection. All non-HTTPS sites have the exclamation mark.

The tapatalk is just an error.

[RGB255_0_0]

I don't get the Tapatalk error. Anyway, this is for all non-HTTPS sites I visit. From BBC to Overclock.net, hotukdeals to reuters. Chrome is showing up all websites without a secure connection with an exclamation.

[Jeroen3]

In january 2017 it gets even worse

[IanB]

I don't get the Tapatalk error. Anyway, this is for all non-HTTPS sites I visit. From BBC to Overclock.net, hotukdeals to reuters. Chrome is showing up all websites without a secure connection with an exclamation.

Apparently it is only supposed to show the insecure icon if the web page contains a password or credit card field.

[orin]

It's time.
Chrome started doing warning icons.

It is not because Chrome wants https, it is because a few things on the page cause rendering errors, one of which is the bloody Tapatalk. The Detail button gives exactly the details what is wrong.

Nope. Refers to the connection. All non-HTTPS sites have the exclamation mark.

It's not an exclamation mark, just an 'i' in a circle, presumably for 'information'.

You get a padlock icon for https connections.

In either case, click the icon and you get a summary of information for the page.  BOTH http and https have a details link which essentially brings up the developer tools with the Security tab selected.

The tapatalkDetect error is just an error in the web page - you'd be surprised at how many web pages have errors that will show up here.  My current gmail session has 86 errors!

I don't see a problem here and the icon actually provides a faster path to the developer tools.

[EEVblog]

It's not an exclamation mark, just an 'i' in a circle, presumably for 'information'.

That is new I have no idea why it shows that now.

You get a padlock icon for https connections.

I see this too which I find incredibly puzzling because I have disabled SSL completely and deleted all certificates on both Cloudflare and the server!

I'm magically no longer getting report of the site being down from Pingdom. I'm not sure it's the fault that fixed itself (likely a Cloudflare problem) or it had something to do with me deleting everything SSL related.

[EEVblog]

I'm sure Dave and Gnif are trying. But I will say this, privacy should be an option for those who want it rather than being left without a choice.

Gnif is currently on holidays so I've been playing and it didn't end well.
Enabling SSL should be pretty easy, as Cloudflare provide the certificate and i basically figured out how to enable evrything on the server as well, but gnif need to do some magic to make it work with nginx. I don't know how to do that.
TLS support would require me to upgrade to a paid plan on Cloudflare.