HTTPS for EEVBlog Forums?

[System Error Message]

i wouldnt call it shaming, just that web browsers dont display the http:// or https:// infront of urls anymore.

Regardless its not worth the extra computing power required. Encryption is required for authentication and editing (like posting something new). For reading using it is just wasted CPU load. google chrome should notify you instead if you are trying to send data without using https or if you are trying to authenticate through http. The mass use of https will just mean needing more CPU for no reason and this is bad for many hosters. Is eevblog considered to be political enough that reading this from china will get you jailed?

And dont talk about the man in middle security stuff. hijacking can be done properly so SSL isnt bullet proof.

[Cerebus]

The whole "Ooh! Let's encrypt all the things!" push is pointless,

No, it's not. If you only encrypt the important stuff someone looking at your Internet traffic has a clear signal marking out important from trivial traffic. If you also encrypt the trivial traffic it makes traffic analysis harder by not flagging 'important' communications.

[System Error Message]

The whole "Ooh! Let's encrypt all the things!" push is pointless,

No, it's not. If you only encrypt the important stuff someone looking at your Internet traffic has a clear signal marking out important from trivial traffic. If you also encrypt the trivial traffic it makes traffic analysis harder by not flagging 'important' communications.

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?

[hammy]

Is eevblog as important as your email, cloud services and online banking?

For my privacy everything is important.

[Cerebus]

The whole "Ooh! Let's encrypt all the things!" push is pointless,

No, it's not. If you only encrypt the important stuff someone looking at your Internet traffic has a clear signal marking out important from trivial traffic. If you also encrypt the trivial traffic it makes traffic analysis harder by not flagging 'important' communications.

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?

Please follow the thread of argument, the context is not merely HTTPS and eevblog but "Let's encrypt all the things!". (As an aside my mail server has been using opportunistic encryption for more years than I can remember, at least 10.) And no, the people sniffing you (insert name of your favourite intelligence agency here) don't already know what's important and what isn't - they are collecting traffic data on everyone and have to sift out the important stuff by algorithmic means. It's been recorded that one of the criteria they use is "is it encrypted?" and if it is they select that traffic for storage; if encrypted becomes the new norm it ceases to be a useful selection criterion and hopefully stops ordinary folks traffic being slurped up into the spies data stores as it becomes too much to handle.

The problem isn't that the spooks are spying on the bad guys and foreign governments, they are spying on everyone and that isn't acceptable and it's behoven on any of us who can do anything, no matter how little that might be, to stop it to do so. [Insert Pastor Niemöller quote here]

Bringing the argument back to the eevblog: Once of the 'trending topics' on the Internet spying front is how hard certain countries are pushing at getting access to technology companies in general and military electronics in particular. The prime method for doing this is launching advanced persistent threats (APTs) at the individual engineers at those companies. This is where things like script and HTML injection come in, and eevblog has a useful concentration of engineers to launch those attacks at. The strongest argument for making eevblog HTTPS is to protect against those types of attack in general (authentication of origin) and it is not in the realm of the impossible or improbable that eevblog may have already been selected as a possible attack vector by some some bunch of spooks with economic or technological espionage on their minds.

(Whoops, I hit send too soon there.)

I suspect that there are a few people here who wouldn't ordinarily think of themselves as targets for the spooks of the world who are going to realise that in this context they are prime targets.

[nfmax]

Bringing the argument back to the eevblog: Once of the 'trending topics' on the Internet spying front is how hard certain countries are pushing at getting access to technology companies in general and military electronics in particular. The prime method for doing this is launching advanced persistent threats (APTs) at the individual engineers at those companies. This is where things like script and HTML injection come in, and eevblog has a useful concentration of engineers to launch those attacks at. The strongest argument for making eevblog HTTPS is to protect against those types of attack in general (authentication of origin) and it is not in the realm of the impossible or improbable that eevblog may have already been selected as a possible attack vector by some some bunch of spooks with economic or technological espionage on their minds.

At last somebody gets it!

[arlipscomb]

A large engineering company I worked for (> 50,000 employees) was attacked by using a local engineering societies web site. The remote site was compromised and configured to deliver malware to visitors based on some social engineering and some knowledge of IP addresses in use. Could the use of HTTPS/TLS have prevented that attack? Doubtful at best.

Now encrypting the login information and password fields have been considered standard fare for at least a decade now.

[StuUK]

Bringing the argument back to the eevblog: Once of the 'trending topics' on the Internet spying front is how hard certain countries are pushing at getting access to technology companies in general and military electronics in particular. The prime method for doing this is launching advanced persistent threats (APTs) at the individual engineers at those companies. This is where things like script and HTML injection come in, and eevblog has a useful concentration of engineers to launch those attacks at. The strongest argument for making eevblog HTTPS is to protect against those types of attack in general (authentication of origin) and it is not in the realm of the impossible or improbable that eevblog may have already been selected as a possible attack vector by some some bunch of spooks with economic or technological espionage on their minds.

At last somebody gets it!

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...

[AntiProtonBoy]

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.

[Cerebus]

Bringing the argument back to the eevblog: Once of the 'trending topics' on the Internet spying front is how hard certain countries are pushing at getting access to technology companies in general and military electronics in particular. The prime method for doing this is launching advanced persistent threats (APTs) at the individual engineers at those companies. This is where things like script and HTML injection come in, and eevblog has a useful concentration of engineers to launch those attacks at. The strongest argument for making eevblog HTTPS is to protect against those types of attack in general (authentication of origin) and it is not in the realm of the impossible or improbable that eevblog may have already been selected as a possible attack vector by some some bunch of spooks with economic or technological espionage on their minds.

At last somebody gets it!

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...

Injection attacks are prevented by authentication of origin, as supplied by TLS, and it has nothing to do with selecting the same passwords for different sites. Injection attacks happen en-route via a compromised router or deliberate traffic misdirection (e.g. DNS cache poisoning, BGP shortest path manipulation or first-to-arrive packet races). Remember, the NSA interdicted Cisco routers being delivered to compromise them, they have proven compromises for many major router brands (e.g. Juniper), the Chinese would have no problems pre-compromising Huawei routers and the Russians no doubt have similar capabilities. If one thinks that any of the major powers doesn't have the capability to interfere with traffic to any given website then one is sadly mistaken.

[madires]

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.

[arlipscomb]

If I were running a business that had an online community attached to it, my worry would be that someone would sit in the middle and harvest account login information. Then when they had enough information start to use those accounts to cause problems. Someone could make a mess over several days that might go undetected for weeks.

[Kjelt]

If configured correctly the forum is totally seperated from Dave's business, an overload on the forum should never interfere with business.

[Cerebus]

Such an attack would require:
- a way to intercept the traffic for a MITM

From Bruce Schneier's blog earlier today, discussing a series of nation-state level 'calibration' attacks seen recently:

There's more. One company told me about a variety of probing attacks in addition to the DDoS attacks: testing the ability to manipulate Internet addresses and routes, seeing how long it takes the defenders to respond, and so on. [Emphasis mine]

You can read the whole thing at https://www.schneier.com/blog/archives/2016/09/someone_is_lear.html.

[madires]

Such an attack would require:
- a way to intercept the traffic for a MITM

From Bruce Schneier's blog earlier today, discussing a series of nation-state level 'calibration' attacks seen recently:

There's more. One company told me about a variety of probing attacks in addition to the DDoS attacks: testing the ability to manipulate Internet addresses and routes, seeing how long it takes the defenders to respond, and so on. [Emphasis mine]

You can read the whole thing at https://www.schneier.com/blog/archives/2016/09/someone_is_lear.html.

Unfortunately a lot of ISPs and carriers don't apply proper prefix flters for the route announcements of BGP peers. There's also RPKI, but not widely supported. We've seen route hijacking by configuration mistakes so many times, still several ISPs/carriers don't care. Now this is misused on purpose. Some people never learn. 

[Cerebus]

Such an attack would require:
- a way to intercept the traffic for a MITM

From Bruce Schneier's blog earlier today, discussing a series of nation-state level 'calibration' attacks seen recently:

There's more. One company told me about a variety of probing attacks in addition to the DDoS attacks: testing the ability to manipulate Internet addresses and routes, seeing how long it takes the defenders to respond, and so on. [Emphasis mine]

You can read the whole thing at https://www.schneier.com/blog/archives/2016/09/someone_is_lear.html.

Unfortunately a lot of ISPs and carriers don't apply proper prefix flters for the route announcements of BGP peers. There's also RPKI, but not widely supported. We've seen route hijacking by configuration mistakes so many times, still several ISPs/carriers don't care. Now this is misused on purpose. Some people never learn. 

I remember sitting in a LINX meeting in 1996 or 1997, after yet another massive route leak, discussing solutions beyond filtering prefixes and here we are twenty years later and it's still a problem. By now RPKI or some similar admittance control protocol ought to have been universal. As it is there aren't even RPKI certificates issued for all of the IPV4 address space.

[apelly]

I'm not feeling particularly verbose or articulate today, but here are a couple of articles I stumbled across this morning while researching unrelated security:

Some interesting points:
https://scotthelme.co.uk/still-think-you-dont-need-https/

Very often people tell me "we don't need HTTPS" and most of the time the justification is based on 1 of 2 arguments. It's either "we don't have a login screen" or "we don't serve any sensitive data". Supporting HTTPS on your site has so much more to offer than just protecting passwords and user's sensitive data. In this blog I'm going to cover some of the great reasons to add HTTPS support to your site that don't have anything to do with the privacy of data exchanged.

Page load times. Relevant to cloudflare. And nobody needs to be told that slow load times directly affect revenue.
https://www.httpvshttps.com/

Compare load times of the unsecure HTTP and encrypted HTTPS versions of this page. Each test loads 360 unique, non-cached images (0.62 MB total). For fastest results, run each test 2-3 times in a private/incognito browsing session.

Observations about where encryption is heading:
https://scotthelme.co.uk/the-encryted-web-is-coming/

Now, more than ever, we are seeing a huge drive towards encryption on the web. In fact, encryption is now being adopted at a rate never before seen. Here are some of the notable things that have grabbed my attention recently and the evidence to back up my claim.

Behind the scenes geek stuff. TLS overhead: https://istlsfastyet.com/

Historically, concerns over performance have been the common excuse to avoid these obligations, but today that is a false dichotomy. Let's dispel some myths.

Random: Check site policies and security in place at your favourite web site.
https://securityheaders.io/?q=https%3A%2F%2Fwww.eevblog.com%2Fforum%2F

[System Error Message]

whether encrypted or not all data is stored. The feds have enough storage even if the whole internet was encrypted. Infact not all headers are encrypted. As i said source and destination can be seen and so are the protocols used.

The other thing is that https security relies on the SSL software stack which has had some updates in the past few years so its not 100% secure. If you really want to defeat spying than use vpn and proxies. Just https alone doesnt help as they probably have the computing power needed to decrypt your stuff in minutes.

[Kjelt]

Just https alone doesnt help as they probably have the computing power needed to decrypt your stuff in minutes.

As long as the client does not offer weak ciphersuites or the server does not accept weak ciphersuites nobody is going to decrypt the data except the client and server. Only exception is if there is a zero day in one of the software codes. It is not for nothing that police and government agencies are lobbying with politics to weaken or abandon encryption, because they are not able to decipher the data.
Thiese kind of statements are scientificly speaking unproven sentimental gossip and are not usefull at all in a discussion. Please keep them to yourself or proof that aes for instance which is the most common used cipher is broken.

[Bud]

As long as the client does not offer weak ciphersuites or the server does not accept weak ciphersuites nobody is going to decrypt the data except the client and server

If by the server you mean the ultimate destination server then in general your statement is not correct. Https can be decrypted by proxies, there are bunch of products on the market for "SSL inspection". Having said that, it may be subject to legal limitations and the network scope (corporate vs public proxies), but this is not the same as "nobody is going to decrypt" claim. SSL decryption may be closer than one may think, example being personal antivirus running right on the user's computer, it may have SSL inspection setting.

[Jeroen3]

Haha. Passwords are not stolen by mitm attacks. They are stolen by SQL injection or other database attacks.

And even then, only password re-users are vulnerable. Don't re-use password people!

[3db]

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 ?  :

[Kjelt]

If by the server you mean the ultimate destination server then in general your statement is not correct. Https can be decrypted by proxies, there are bunch of products on the market for "SSL inspection". Having said that, it may be subject to legal limitations and the network scope (corporate vs public proxies), but this is not the same as "nobody is going to decrypt" claim. SSL decryption may be closer than one may think, example being personal antivirus running right on the user's computer, it may have SSL inspection setting.

I might misunderstand you but if you have a TLS connection with a proxy you should have the certificate of that proxy on your browser, eg you have once accepted the trust of that proxy.
If not you can not setup unknowingly a TLS with that proxy. Even if you setup a TLS through a proxy it will only terminate and setup a new TLS connection with the destination server if it can access the datapackets, and you can see that this is happening because the certificate of the destination server is or not shown or it is signed by the proxy.
So left or right you know someone is in between and you should be aware of that.

If you directly setup a TLS connection between your computer and the destination server no-one can interfere with that.

[EEVblog]

That was getting onto 2 years ago. Has anything changed in the last 2 years?

Not that I'm aware of, but you'd have to ask gnif again.
As for other forums, most other forums I use do not use https.
Examples of ones that do are Adafruit and Sparkfun but you'd expect them to use it because their entire site is based around and ecommerce sales focus that needed that, so the forums https just came along for the ride.

[madires]

If by the server you mean the ultimate destination server then in general your statement is not correct. Https can be decrypted by proxies, there are bunch of products on the market for "SSL inspection". Having said that, it may be subject to legal limitations and the network scope (corporate vs public proxies), but this is not the same as "nobody is going to decrypt" claim. SSL decryption may be closer than one may think, example being personal antivirus running right on the user's computer, it may have SSL inspection setting.

I recommend to read something like Network Security by Kaufman, Perlman & Speciner to get your basics right. The boxes you're describing are web proxies with fake certificates. Your web browser connects to the proxy, not the web server. And if you would check the certificate, you would detect that easily. Those SSL inspection devices can't decrypt any https traffic not destined to themselfes as a web proxy. For a more reliable detection of fake certificates and a big red alert pop-up (users are lazy) we might get a RFC for web certificates via DANE.