New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Are you kidding? There's tons of attack vectors that a user is subjected to if the traffic isn't over HTTPS.
One example: https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)
You could have your banking or credit card information stolen by getting the wrong recipe from Sally. There's no reason to not encrypt traffic, and it sounds like you don't know much about security.
If ISP wants to log the sites you visit, it's sufficient to log all DNS requests.
The whole idea of forcing all sites to have HTTPS is stupid in my opinion. This is just another typical corporation (in this case Google Inc.) showing their muscles and power over internet.
I'm not kidding. And if sites that need the security set it up properly this isn't an issue.
@sarah,
I don't know all the details either, but my understanding is that the packages installed from a package manager are not verified by checking their hashes. They're digitally signed using public/private keys. Your OS install has the public key and checks the signature after getting the package. If the file is modified in transit or at rest on the server, the signing breaks and you'll know when your package manager starts throwing a fit.
Only domain names, and only when SNI is used.
No. "Downloaded files" are not any different on the protocol layer from any other HTTP request and response; when using TLS, the ISP cannot see what files you're downloading.
Depending on what other protective measures are used, an ISP might be able to infer what file you're downloading, though, if 1) they know ex which files are offered and how big each is, 2) each file has a distinctly different size, 3) HTTPS connections are not reused, and 4) they look at the amount of data transmitted over a connection.
Package signing and TLS protect from different threat models, and should be used together. TLS is for protecting the transport (ie. connection) from snooping and modification, whereas package signing is for protecting the data from modification (but not from snooping!), in particular in situations where infrastructure is otherwise compromised. This is why package signing should always be done 'offline', as well.
There's some limited overlap; for example, package signing will indirectly also prevent an ISP from modifying the package you're getting, because "the ISP modified the data" vs. "an attacker the server modified the data" are indistinguishable to the user. However, there are also points where they don't overlap; for example, package signing won't prevent an ISP from seeing exactly what packages you're installing, whereas TLS will.
This is true for a lot of security mechanisms; there's coincidental overlap between them all the time, but there are also points where they inherently don't overlap and that's why multiple mechanisms are used.
I agree, and so do browser vendors! The problem is that you can't 'hard-deprecate' plaintext HTTP without upsetting a lot of users, and that's why browser vendors are instead gradually introducing barriers against using plaintext HTTP. That includes the 'not secure' marker (which couldn't be introduced earlier, because plaintext HTTP was still widespread enough that it would cause 'error blindness'), but also things like "you can't use new browser features if you don't use TLS" (which incidentally I have issues with for different reasons).
The TL;DR is that plaintext HTTP is indeed being deprecated; it's just being done in a way that produces the least drama and broken infrastructure. Given the widespread deployment, that's really the only way.
Read my post again. It's not just about modification; it's also about privacy.
EDIT: But hey, if you want to stick with your recipe modification example; there are certain ingredients that are harmless when used in moderation, but can kill quickly when overused.
Not directly, no; TLS is only concerned with ensuring the privacy and integrity of network data transmission. In other words: it makes sure that you, as the client, receive exactly what the server sent without anybody else ever seeing it, and vice versa. That's its only responsibility.
The one sort-of-exception here is with XSS; while TLS doesn't prevent it directly, it indirectly does prevent some unusual attacks that involve third parties (think "malicious coffeeshop WiFi operator") injecting JS into a site's assets, to circumvent CSP headers. But these are rare, and TLS isn't explicitly designed to protect against that, it's just the logical consequence of preventing any kind of modification of the data by third parties.
https://en.wikipedia.org/wiki/Information_security#Overview
tl;dr security: confidentiality, integrity and availability (CIA) of information
The integrity part is the "trusted source / website" / "data you actually wanted" part.
then every router setting page will show insecure because it cannot have a cert for it :P
What? HTTP is an issue in and of itself, no matter what website is visited. HTTPS is a better guarantee that you're net getting a hijacked HTML page, which is a better guarantee that you aren't going to undergo some malicous attack other than "oh no, it said to use 3 tea spoons instead of 1".
I respect you and your opinion; and I value your posts on LET because you know stuff. But I don't have the time to read it again. I read it once and responded, thanks.
I think the point I'm making is that I don't care that someone knows I'm baking cookies. And as @angstrom mentioned above, a person can't ask/demand/want privacy about everything (such as baking cookies) and then post everything they do on Facebook, etc. It doesn't add up.
I value privacy just as much as the next person. And I think that for a lot of sites TLS should be there (e.g. every CMS since a user has to login and that needs to be private). But simple static sites that are obviously uncontroversial? Why waste time.
If we're going to say TLS everything then like @raindog308 said, let's deprecate the HTTP standard altogether.
And how could I use Let's Encrypt for localhost?
Uhhh
You're wrong. It's not just privacy / confidentiality. It's also about integrity and helping limit attack vectors. Those "uncontroversial" website can be hit with a man-in-the-middle attack like any unencrpyted packet and be spoofed to cause damage to a user.
Deprecate HTTP? HTTPS is HTTP over SSL / TLS. This is nonsense.
So, here's the problem with that rationale: there are other people who use the internet, not just you. And they might have different expectations of their privacy. And if a site doesn't support TLS, they are not being given that choice; they are forced to communicate with the site in plaintext, with absolutely no guarantee that it wasn't snooped on or modified by somebody else.
Not everybody liveblogs their life to Facebook. Not everybody has the same uncaring attitude about their reading privacy that you do. The reason everything needs to be TLS, is because that accommodates everybody, not just the people with your worldview. It's incredibly arrogant to say "widespread TLS is unnecessary because I personally don't care".
This makes no sense. "The HTTP standard" defines a request/response protocol, and it's the exact same protocol that's being used for HTTPS - which is just "HTTP over TLS". What @raindog308 is suggesting is deprecating plaintext HTTP. It doesn't change anything about the HTTP standard.
And like I already explained, that deprecation is precisely why this change is occurring.
That's not new...
Nice discussion people keep it up.
Absolutely. But some things simply don't need all of it.
Obviously HTTPS is HTTP over TLS. What I, and originally raindog308, was saying is simply have the spec say TLS is required and hard code browsers, servers, etc. to not operate any other way.
Don't get me wrong. I think the world is headed in that direction (no HTTP), but my original comment focused on Google penalizing sites for not using HTTPS. Again, it's just not that important for EVERY site.
And for the record: All my (and my clients') sites do use HTTPS. Heck, even stuff on my LAN uses it. Because for me it's easy enough to set up. But I think the push for every site is unwarranted at this point. We should be focusing on HTTPS for sites that need it, 2FA, and a better public trust system because the whole certificate authority design is crap.
Google could simply put an optional advanced security setting like "Allow only HTTPS websites". As such, people that want this security can actually have it, without enforcing it on other people or public services.
I am not a Chrome user or lover, but such option currently exists as transitional factor to say the least?
Again: this is not your decision to make, it's the decision of the user. Therefore, you err on the side of caution, and provide HTTPS everywhere.
This does not need to be in a spec, and it is already happening in browsers. That's literally the whole fucking reason for the change you're complaining about, as I've now pointed out twice. Seriously, read up on what this shit is actually about instead of going with your gut feeling.
HTTPS is not an "advanced security" feature, it's a basic necessity that should have been the default from the start. And like I've now explained numerous times in this thread, TLS cannot work without cooperation from the server administrator, which is why everything should offer it.
"Enforcing it on other people or public services" is a completely desirable and necessary thing, not something to prevent.
This change was announced years ago, and has been gradually introduced for the past several years, in the pre-announced stages. The transition period has already happened, and is now over.
That's a valid point. There are certainly alternatives for some people who need more, such as VPNs and proxies. I also did mention that my opinion is based on sites that are obviously uncontroversial. Some sites I host are religious (for lack of a better word) in nature, I absolutely think these should be encrypted. But a "DIY wall shelf"? That can wait.
I'm incredibly privacy conscious, as I mentioned a few comments ago with all the sites I run being HTTPS. And I limit the information I expose to the best of my extent. I'm not on social networks and my posting activity is largely just a handful of forums like this.
Again, my point was that penalizing all sites for not having HTTPS is unwarranted.
Yes. I clarified this in a more recent comment above as my word choices were poor when I originally said that.
You're starting to take my words out of context, which is understandable considering how much bits and pieces are being written and quoted across multiple posts.
No, there aren't. Neither VPNs nor proxies can protect the 'last mile'. There is exactly one way to protect traffic from end to end (ie. from client to server), and that is TLS or other server-provided transport encryption. It is an absolute inherent technical impossibility to provide these protections without cooperation from the server administrator. No exceptions, no tricks, no workarounds.
(If your VPN/proxy provider claims otherwise, they are lying, as any competent network engineer will be able to tell you.)
Once again: this is not a decision you can make for other people. Everybody has their own privacy requirements, their own definition of what is 'sensitive', and their own life in which different things are controversial from other people's lives.
It's not 'penalizing' sites at all. It's clearly communicating the risks to the user, and that is absolutely warranted. If you don't want your site to be called "Not secure", then make it secure, don't complain at the guy pointing out the insecurity.
Again, context. You're taking what I've written out of context. That changes the meaning. I don't think you're doing it on purpose. But it makes it difficult to have a reasonable discussion, especially since I'm typing on mobile, which is a lot of work.
@JustAMacUser OK, two of us didn't understand what you meant.
HTTPS on every website would help prevent banking or other sensitive information being stolen. Do you want more or less banking information being stolen? HTTPS can potentially improve the security of everything and everyone, and casual users should be alerted if they're being subjected to greater risk, which is what Google / others are trying to do.
^ Clarifying: you can get your bank information stolen through any website, not just an insecure banking website.
>
That is your opinion only. I do not consider HTTPS as "necessity", "default", "should offer", "enforcing", "desirable", or "necessary thing". HTTPS should not be something to be prevented either because it's not something bad. HTTPS is just important for websites involving sensitive or confidential information that absolutely require encryption on transfer.
Internet has a huge amount of websites, blogs and static pages that do not need such "cooperation from the server administrator" to begin with.
You're wrong. I've already addressed all of this in my very first post in this thread. TLS (or other equivalent transport security) is a basic necessity for secure communications infrastructure.
... and the flat-earthers have emerged.
HTTP isn't the only thing that's insecure here..
>
You were addressing @JustAMacUser, but let me react to this. My/Our attitude is not "widespread TLS is unnecessary because I personally don't care". At least for me, the attitude is more "I don't necessarily mind if a given static site doesn't have TLS".
I don't necessarily mind not because I would be pleased if someone were to snoop on me just at the moment when I queried the site but rather because I subjectively judge the fact that I queried that site at that moment to be so incredibly insignificant/uninteresting to anyone that any risk that I take by querying that site at that moment to be so small compared to the ordinary risks of everyday life (e.g., driving to and from work, getting sick, losing a family member) that I simply don't have the psychological capacity to worry about it.
But perhaps you're right and I should worry about it.
(In any case, thanks for your patient and instructive replies above.)