[HN Gopher] Increasing HTTPS Adoption
___________________________________________________________________
Increasing HTTPS Adoption
Author : inian
Score : 78 points
Date : 2021-07-14 17:12 UTC (5 hours ago)
(HTM) web link (blog.chromium.org)
(TXT) w3m dump (blog.chromium.org)
| mgarciaisaia wrote:
| > In particular, our research indicates that users often
| associate this icon with a site being trustworthy, when in fact
| it's only the connection that's secure.
|
| I had the idea that browsers were showing a grayed-down padlock
| for standard HTTPS certificates (ie, "connection is encrypted")
| vs a full-blown green icon with the company name next to it for
| the HTTPS certificates that also validate identity (DV? EV? I
| don't recall the meanings and acronyms).
|
| I guess that's where we should go now: make HTTPs the default
| (thus showing a standard icon that doesn't call for any
| attention), a big red ugly icon alerting non-encrypted
| connections, and a green one with identity attached meaning you
| can indeed trust this particular site to really be your bank.
| forty wrote:
| I think most browsers have stopped displaying EV certificates
| differently for a while.
| nightpool wrote:
| Yes, the goal was that EV certificates would fill this gap.
| However, research showed that they didn't meaningfully affect
| user behavior[1], it was easy to get CAs to issue EV certs for
| company names that misled the user into thinking the phishing
| site was secure[2], and it was even possible to issue colliding
| EV certificates simply by registering your company in a
| different jurisdiction[3]. So in 2019, Chrome, Safari and
| Firefox all removed the "special" treatment of EV certificates.
| (In Safari it's still distinguished by a green vs grey lock
| icon, I believe)
|
| [1]
| https://chromium.googlesource.com/chromium/src/+/HEAD/docs/s...
|
| [2] https://typewritten-archive.cynthia.re/writer/ev-phishing/
|
| [3] https://arstechnica.com/information-
| technology/2017/12/nope-...
| kevincox wrote:
| This is also still a slightly different concern. EV ensures
| that you are talking to the company that you think you are
| talking to (in theory, in practice company names are not unique
| and not a good identifier) not that the company that you are
| talking to has good security.
|
| Put another way users think "This site is secure" not "I am
| securely connected to the site I think I am".
| vbezhenar wrote:
| I think that there should be some maintained white-list of
| important websites. I know that many people won't like this
| idea, but I think that for most users it would be better if
| Google domains, Facebook domains, etc were displayed
| differently, for example with green background, because that's
| what overwhelming majority of users are visiting every day and
| that's what most scams are targeting. Something like top-1000
| websites in every region should qualify for that treatment.
|
| Also I would include government websites to this list.
| gorkish wrote:
| This is already a thing; it's called the HSTS preload list.
|
| The sites on it are not set apart visually for the same
| reasons that browser vendors stopped distinguishing EV
| certificates.
| flowerlad wrote:
| What is sorely lacking today is an encryption solution for the
| intranet. When you are transferring confidential data (such as
| salary info) over the network in intranet situation we need to
| encrypt the information to prevent casual snooping using tools
| such as Wireshark. We don't need to verify the identity of the
| server because that's typically not a problem on the intranet.
|
| Self-signed certificates used to be the solution in this
| situation. But browser makers have made it significantly harder,
| if not impossible to use self-signed certificates, by not
| allowing the user to visit sites that have self-signed
| certificates.
|
| We need a simple solution for this -- a solution that works even
| for small businesses that do not have an IT department. (That
| means installing certificates on each end-user's machine is not a
| reasonable solution.)
| metafunctor wrote:
| If you have servers in your intranet, but don't have enough
| expertise to install a CA server and a CA certificate on end-
| users' machines, maybe move to a cloud based solution instead
| of hosting your own.
| qbasic_forever wrote:
| This is the hard truth. With a business and internal data,
| _especially_ customer data, you need to think of the
| liability if any of that data leaks or is accessed
| inappropriately. It will not look good in a lawsuit if a
| judges asks why data was so easily stolen and your response
| is that you didn't know some exploit was possible and didn't
| want to pay for experts to secure access to it. Managing
| certs, securing an internal network, etc. are just part of an
| ever evolving and changing security and threat landscape. You
| need to dedicate resources like time and money to constantly
| stay on top of it.
| dvdkon wrote:
| Many vendors of internal tools don't have cloud offerings
| and even if they did, I wouldn't trust it considering their
| current security record. It would be a good CYA strategy,
| but that's about it.
| dec0dedab0de wrote:
| Self signed certs on an internal network are more secure than
| CA signed cert on a cloud.
| magicalist wrote:
| > _Self signed certs on an internal network are more secure
| than CA signed cert on a cloud._
|
| Not if your threat model is someone who already has access
| to the local network (which has no one managing it)
| snooping on traffic.
| slownews45 wrote:
| There is a good one, but everyone is pushing the craptastic /
| megasize management solutions - so I don't think there is
| anyone out there yet for the 15 machine non AD (or light AD)
| domain type setups with third party stuff.
|
| The solution would be to allow self signed + pinning.
|
| You click to a new box on your network with a self signed cert.
| Instead of blocking you basically (yes, you can flag flip, go
| to advanced etc etc), it says, hey this is self signed cert, do
| you want to pin it? You say yes. It pins that cert to that
| internal IP.
|
| Now you've got encryption.
|
| Let's say in a rather far out case someone spoofs internal
| resolution. You are generally already owned at that point, but
| if they redirect IP X to a new cert, browser could have a popup
| saying - heads up, the cert for this IP now mismatches. Be very
| careful and do the current basic block/lockout approach.
| staticassertion wrote:
| > Let's say in a rather far out case someone spoofs internal
| resolution.
|
| Seems trivial. Why wouldn't they?
|
| > You are generally already owned at that point
|
| Well, _you_ might be, since your network is relying on self
| signed certificates with no PKI.
|
| > heads up, the cert for this IP now mismatches.
|
| Good thing everyone is already trained to click through
| certificate warnings.
|
| Or you could just do PKI properly and avoid the entire issue,
| or not have an intranet and avoid the entire issue.
| altantiprocrast wrote:
| > Good thing everyone is already trained to click through
| certificate warnings.
|
| With a proper UI there would be different messages when a
| cert mismatches compared to when a new cert is seen or the
| previous cert was about to expire. (Quite like Gemini
| browsers)
| geofft wrote:
| In the past, there were messages that specified exactly
| what was different about the situation, and they were by
| no means "proper UI":
|
| https://docs.jboss.org/jbossas/guides/webguide/r2/en/html
| /im...
|
| In fact, in the past, browsers used to helpfully give you
| warnings whenever you _started_ using SSL:
|
| http://acc6.its.brooklyn.cuny.edu/~core51/labs/extralab_f
| ile...
| altantiprocrast wrote:
| TOFU like SSH or Gemini?
| vbernat wrote:
| That's already what Firefox does. Despite not saying it
| clearly, if you accept a self-signed certificate, it will be
| used as long as it does not change.
| [deleted]
| Telemakhos wrote:
| It sounds like you just want to encrypt individual files. Most
| major office software suites like MS Office will have an
| encryption feature so that you can password-protect
| spreadsheets. The other easy solution requires certs, but not
| the kind you're thinking of: if you want to protect individual
| files and know who should have access, you could encrypt them
| using openssl (maybe write an app to wrap it up nicely) and
| S/MIME certs that could also encrypt your internal email. If
| you know what you're doing, you can provision out those keys
| and keep a copy in escrow for data retention policy and
| accountability.
| whoisburbansky wrote:
| This works if you're emailing random files around for all
| information transfer, but it feels like GP is talking about
| the case where such information is accessed through intranet
| websites?
| wizzwizz4 wrote:
| > _Most major office software suites like MS Office will have
| an encryption feature so that you can password-protect
| spreadsheets._
|
| I don't know about now, but in the .xls days that _wasn 't
| encryption_. You could bypass it by rewriting the file's
| header.
| nijave wrote:
| You can use a VPN e.g. overlay network
|
| As an added bonus, it keeps working regardless of your location
| geofft wrote:
| Name your internal services after some valid DNS domain that
| you own. Options include
|
| - use split DNS, where hostnames like "hr.example.com" resolve
| on your internal network but not externally
|
| - use split DNS for a subdomain, so everything under
| "corp.example.com" points at your internal network and you use
| https://hr.corp.example.com (which might be easier to manage -
| you just reserve "corp.example.com" on your public DNS)
|
| - buy a completely separate domain name like examplecorp or
| something
|
| - go full beyondcorp and make https://login.corp.google.com
| available on the public internet, and rely on SSL + strong
| authentication (like two-factor) instead of people being on the
| internal network (as a bonus, this approach to IT makes things
| more straightforward if, hypothetically, there was a global
| pandemic forcing people to not be in the office for over a
| year, idk, that might not be a realistic business risk)
|
| Now that your services are running on a DNS name you control,
| you can get real, valid SSL certificates for them. Assuming you
| didn't go with that last option, you can
|
| - use Let's Encrypt DNS challenges, by temporarily adding TXT
| records mapping to your internal names
|
| - use Let's Encrypt HTTPS challenges, by temporarily (or
| permanently) running a web server in external DNS that
| corresponds to your internal names
|
| - pay for a wildcard certificate from a vendor, which costs
| under $100/year
|
| The one risk here is that names of all real SSL certificates
| are logged publicly (for Certificate Transparency, to help
| track mis-issuance). So if you happen to enjoy running web
| servers named things like secret-plan-to-acquire-foobarcorp-on-
| july-30.corp.example.com, then you want to go with the wildcard
| option. If the names you have are things like "hr" or "wiki",
| you'll be fine with the Let's Encrypt option.
|
| This approach requires no installing of certificates on end-
| user machines _and_ no asking users to click through any
| dialogs _and_ no risk of people on the internal network
| spoofing websites and doing a man-in-the-middle attack (which
| is only ever so slightly harder than using Wireshark).
| nine_k wrote:
| How come there is none?
|
| Set up DNS in whatever way you prefer. Give each service a
| name.
|
| Create a self-signed root cert, push it to all machines via
| whatever administrative update tool you use, or just walk
| around a small office with a flash drive.
|
| Create an intermediate cert. From it, create certs for all
| services that need one, and push them.
|
| Voila, you can use https without warnings.
|
| Am I missing something?
| yodelshady wrote:
| Yup, but I'd go even simpler. Imagine An OS-level switch to put
| arbitrary network traffic over TLS.
|
| I'm sure you'd need various switches for edge cases, custom
| keys etc, but... _imagine_. Quick and dirty network apps? Half
| the security battle is done. Crusty endpoint security solutions
| downgrading your encryption? No need. Malware sending an
| encrypted traffic? Stands out like a sore thumb, because it 's
| the _only_ thing not sending cleartext to the socket.
|
| Yes, if your OS is compromised, your processes encryption is.
| Guess what - that's already the case.
| amarshall wrote:
| Direct p2p over Wireguard or similar is a solution here.
| gsich wrote:
| I imagined it and it looks like SSH.
| irrational wrote:
| I work for a Fortune 500 company with a huge IT department, and
| even we have trouble with this. Some intranet sites will work
| on certain browsers but not others because of certificate
| issues. So, it is clearly a problem for both large and small
| companies.
| air7 wrote:
| I think that if you are worried about someone sniffing salary
| info in your org, there are deeper problems to sort out.
|
| There isn't really something like "casual sniffing". It has to
| be done deliberately and with full intent. Not to mention with
| the right timing or long duration and non trivial technical
| knowledge. It isn't really possible to protect against such an
| adversary (for example, even with self signed certs, he can
| mitm the connection and resign it himself), and therefor imo,
| its better not give a false sense of security.
| [deleted]
| LinuxBender wrote:
| They way I have dealt with this in the past was to buy a
| wildcard subdomain cert and only use that subdomain internally.
| The downside is that you have to delegate that subdomain from
| your public DNS to your internal DNS or do split horizon/split
| view. Both have caveats and require some thinking ahead. This
| is not a free solution, but I would consider it affordable for
| any small business. It is certainly much less complicated than
| setting up internal CA's and avoids the opex expenses of
| managing an internal CA and greatly simplifies managing
| certificate expiration.
|
| e.g. *.internal.some.tld
|
| You may even be able to find a CA that will sell you a SAN cert
| with multiple wildcard subdomains listed. They lose money doing
| this and most will require you to buy a different wildcard cert
| for each sub-domain. There are no technical or CAB limits to
| wildcard subdomain SAN certs, only business policy per CA. If
| CAB have added any recent restrictions that I am unaware of, it
| would be for purely monetary reasons as the SAN RFC's have no
| restrictions on the number of names last I checked.
|
| e.g. one wildcard SAN cert with names like
| *.sfo1.dev.some.tld *.uk1.dev.some.tld
| *.dev.some.tld
| ryandrake wrote:
| > We don't need to verify the identity of the server because
| that's typically not a problem on the intranet.
|
| Sorry, not a security expert. What is the point of encrypting
| if you're not also sure you're sending the encrypted data to
| the right entity?
| gruez wrote:
| It helps against passive observers. This might not be very
| important over wired, but on WPA-PSK setups, knowing the
| network password allows you to eavesdrop on communications by
| any of the computers.
| staticassertion wrote:
| Why would an attacker in your intranet who's looking at
| your network traffic be passive? When people talk about
| passive attackers they're talking about the NSA/ your ISP,
| not someone who's hands-on-keyboard sniffing traffic.
|
| There's virtually no reason to do encryption without
| authentication in your intranet.
| spijdar wrote:
| Encryption without signing is arguably more useful than not
| encrypting at all, although there's an argument that non-
| signed encryption gives a false sense of security that
| encourages bad practice.
|
| However,
|
| > we need to encrypt the information to prevent casual
| snooping using tools such as Wireshark.
|
| Given this goal, signing _is_ necessary. If you 're not
| signing the encryption, you can use a tool like Wireshark
| combined with Bettercap to man-in-the-middle the encrypted
| session, and there's no point.
| staticassertion wrote:
| > We need a simple solution for this -- a solution that works
| even for small businesses that do not have an IT department.
| (That means installing certificates on each end-user's machine
| is not a reasonable solution.)
|
| I don't get it. Why even have an intranet then? Use Google
| Drive to share files, or Dropbox, or whatever. Why do you have
| an intranet at all if you don't want to manage an intranet?
| sam_lowry_ wrote:
| Because Active Directory.
| geofft wrote:
| AD has a built-in certificate authority, and installs the
| root CA on domain-joined machines....
| staticassertion wrote:
| Could you elaborate? There's Azure AD, or you could do
| yourself a massive favor and not use AD at all. And like...
| why would you want AD and an intranet but not someone to
| manage it at all? Recipe for disaster.
|
| The simplest solution to this problem, by far, is to just
| avoid it entirely. Don't have an intranet. Don't manage AD.
| Just don't do those things.
|
| Pick an identity provider, pick a file sharing service,
| pick a video chat service, and set up SSO for them. It's 0
| maintenance, far safer, and far easier to use.
| isatty wrote:
| My "internal" (local hosts + server nodes) are on its own VPN
| with wireguard. Even with a VPN, I've letsencrypt provided
| certs on some of em because it's nice, but it's not strictly
| necessary. People being able to know that I've things running
| in my own /8 is not a major security problem.
| qbasic_forever wrote:
| > we need to encrypt the information to prevent casual snooping
| using tools such as Wireshark. We don't need to verify the
| identity of the server because that's typically not a problem
| on the intranet.
|
| If somebody is on your network snooping on packets with
| wireshark, they can easily be poisoning ARP or DNS to redirect
| and man in the middle all your traffic too.
|
| Your complaints come down to certificate management. Spend some
| time looking at group policy and cert management tools--there
| are tons of things in this space. Or... hire a IT person to do
| it, that's how business works. X509 certs are well established
| and trusted as a way of securing internal networks. They aren't
| perfect and they have some warts, but deployed properly they
| are secure.
| AnIdiotOnTheNet wrote:
| I think that's exactly what parent is getting at though: it's
| a pain to manage certs for your own internal stuff and even
| worse for third party stuff in your environment. Rather than
| say "well, just hire more IT people" we should really come up
| with a simpler and easier solution if we want to actually see
| adoption.
| qbasic_forever wrote:
| Like I said, spend some time to investigate the space.
| There are lots of tools to ease the burden of running your
| own internal CA. For example:
| https://smallstep.com/certificates/ But really you probably
| want to use your OS' group machine management systems, like
| AD on Windows, to handle this with lots of machines.
| hultner wrote:
| That looks really nice, bookmarked for later. In general
| I agree with the previous commenter, Let's Encrypt made
| TLS easy on the public net, but for small
| teams/organizations TLS in local networks with local host
| names is still a pain.
| [deleted]
| tinus_hn wrote:
| The simple solution is a local certificate authority which is
| added to the users' browsers. It can deliver certificates
| automatically or manually.
|
| This is one of the services provided by Microsoft Windows
| servers, or you can roll your own. It's not hard and scales
| whatever way you want.
|
| Expecting browser vendors to weaken security to avoid this tiny
| amount of work is backwards and will never happen.
| JoshTriplett wrote:
| > The simple solution is a local certificate authority which
| is added to the users' browsers. It can deliver certificates
| automatically or manually.
|
| I wish it was possible to add a certificate authority and
| restrict its usage to non-Internet servers (e.g.
| *.company.example).
|
| (This is theoretically possible if the CA bakes that in,
| though not all TLS stacks support that. It isn't possible via
| local browser configuration.)
| zaik wrote:
| You can get a Let's Encrypt certificate for an internal
| subdomain:
| https://security.stackexchange.com/questions/103524/lets-enc...
| Hamuko wrote:
| Yeah, this. I have a dedicated domain for my internal network
| (it's just 9EUR per year so might as well) and just use a LE
| certificate with the DNS verification, so no need to have any
| external web traffic.
| dheera wrote:
| One of the problems of that is now you need to list all your
| internal IP addresses in a public DNS server. It shouldn't
| theoretically be an issue but it might be stuff you don't
| want to just lay out there in public view just in case.
|
| Also you might just not want a domain like "my-top-secret-
| project.amazon.com" to actually exist and resolve to an IP
| (even if an intranet IP) in public DNS, but you might still
| want an easy-to-remember intranet hostname that employees can
| use.
| amarshall wrote:
| You don't need to if you use ACME DNS challenge. I have
| split horizon where the ACME creates the temporary
| challenge record, LetsEncrypt sees it, and then the record
| is removed. There is never a public A record, and the
| window for enumerating the challenge record is short.
|
| That said, I never really understood worrying about
| exposing DNS records because someone has to brute-force
| enumerate the domain names, and because it just obfuscates.
| I do split horizon for different reasons and am currently
| moving away from it.
|
| Regardless, if you _do_ care, you should be concerned about
| certificate transparency logs. The "workaround" for that is
| wildcard certs.
| hultner wrote:
| LE publishes all issued certs so you might as well just
| keep it public anyway in that case.
| Hamuko wrote:
| Wildcard certs?
| edoceo wrote:
| Yep. The CN is something like "*.edoceo.com"
|
| And you can make self-signed too.
| amarshall wrote:
| Yes, I said this. Wildcard certs, as I mention, largely
| avoid the issue because it's just one cert for a higher-
| level domain and largely uninteresting from an
| information disclosure perspective, at least compared
| with individual domain certs.
| Hamuko wrote:
| > _One of the problems of that is now you need to list all
| your internal IP addresses in a public DNS server._
|
| You don't actually. You can just have them resolve in your
| local DNS server alone.
|
| My current setup is that the public DNS records for my
| internal network just return CNAME records, so
| "mail.myserver.com" has a CNAME record to
| "mail.myserver.internal" and my private DNS server has an A
| record for "mail.myserver.internal".
| hultner wrote:
| I'm going to steal this one, I've never thought about
| this.
|
| Also useful for local development with mdns. E.g.
| MacBook-X.local as an CNAME:
| "MacBook-X.internal.hultner.se CNAME MacBook-X.local"
| should just work for LE on my local dev machine when
| roaming between the home, office or on the go and the
| actual IP changes wildly.
| jbverschoor wrote:
| Still, you're exposing your infrastructure.
|
| It's kind of nice to know that there is a
| mongo1.profiles.company.com somewhere.
| aaomidi wrote:
| You can use wildcard certificates so you're not exposing
| any infrastructure.
|
| Also, you should really consider all your subdomains to
| not be private information. It's risky to build security
| based around that assumption.
|
| Tons of DNS services actually sell their queries, and
| those can be used to reconstruct these "private"
| subdomains.
| Hamuko wrote:
| You can just obfuscate your names if you really need to
| keep it hidden.
|
| profiles.company.com? coffee.company.com.
|
| mail.company.com? tomato.company.com.
|
| passwords.company.com? tincan.company.com.
|
| If you're really paranoid, you can just flood a bunch of
| misdirects in there as well. If you need 10 internal
| subdomains, add 100 subdomains with random CNAMEs.
| 1vuio0pswjnm7 wrote:
| "But browser makers have made it significantly harder, if not
| impossible to use self-signed certificates, by not allowing the
| user to visit sites that have self-signed certificates."
|
| What business are browser makers in. How do they make money.
| Why are browser makers the ones deciding what users should and
| should not be allowed to do.
|
| Which goal is more important to the browser maker:
|
| 1. protect the user against the possibility of the wrong
| recipient possibly receiving an encrypted message (which she
| cannot decrypt)
|
| 2. require that the user must use the browser maker's software
| to "verify" the server (via a certificate)^1
|
| The underlying assumption with #2 is that the user has no
| possible means of verifying a certificate other than the
| browser maker's software. Like on a corporate intranet, on a
| home LAN, I use another program, a proxy bound to the loopback,
| to verify certificates.
|
| Chrome throws a warning "Your connection is not private.
| Attackers might be trying to steal your information from ____".
| That's a guess and it's wrong. The connection is from the
| browser to the loopback. The server certificate has already
| been verified by the proxy. I do not expect Chrome to figure
| that out, the warning is fine (the keylogger is creepy), but I
| do expect an option in the browser to turn off certificate
| verification. This is not an uncommon option in other TLS-
| enabled software.
|
| It is very difficult for me to believe that Google's self-
| interest does not factor into these design decisions. It is
| always possible to spin the explanation for any design decision
| at a "tech" company to be for the benefit of users. That does
| not necessarily mean it is the whole truth. It may not be full
| disclosure. We have no way of knowing. Facebook and Twitter
| collected phone numbers under the guise they needed them for
| "authentication" but it was later shown they were using them
| for advertising. Then 533 million Facebook user accounts many
| which included phone numbers became available to the public,
| not just "friends".
|
| https://www.wired.com/story/twitter-two-factor-advertising/
|
| 1. Consider that we just witnessed the browser maker with the
| most users, who also has the majority of search engine users,
| video hosting users, webmail users, online ad services users,
| etc., etc., launch an experiment and proposal to start tracking
| users through its browser instead of via cookies. Ideally, it
| would be best for users if this company, which effectively
| controls much of the world's web traffic through its search
| engine, did NOT also make a web browser.
| geofft wrote:
| I'm not sure I follow your argument, because, first, no major
| browser maker is in the business of selling their web browser
| software, and second, if you're using the browser maker's
| software to verify the server, you already have access to it.
| So even if they were selling it, you've already paid for it.
|
| Google's self-interest _does_ factor into these decisions,
| though: Google 's interest is in making more people use and
| trust the internet. The more people who feel comfortable
| buying things online, for instance, the more ads they'll
| click from online sellers. The more businesses who feel
| comfortable selling things online, the more ads they'll buy,
| and thus the more profit Google will get.
|
| So it's important to Google that the internet remains
| perceived as a secure and trustworthy place to do business.
| If users are in the business of making judgment calls about
| certificates, some fraction of the time they'll be wrong -
| and they aren't going to say "Oh, I made a mistake," they're
| going to say (correctly, even) "Oh, doing secure transactions
| on the web is too difficult."
|
| There are a whole lot of ways in which Google's interests are
| badly biased against end users, and as you mention FLOC is a
| perfect example. Wanting the web to be secure is not actually
| one of them, though.
| austincheney wrote:
| I thought about that, but have not fulfilled it. I wrote an
| application designed to be private and one-to-one. This
| particular application allows sending of texts, and file system
| segments directly from the browser. Encryption would just be a
| matter of one time public key exchange. I can do that just
| using the Node crypto API. No central authority needed... yet.
|
| The problem is that identities can be faked easily if the
| application allows anybody to spin up a new instance/identity
| with few commands. The standard solution to this is centrally
| managed certificates (certificate authority). A user should
| always challenge the identity of the remote party against an
| agreed upon third party to verify trust before any encryption
| occurs. This is more challenging.
| thayne wrote:
| Not to mention that if you set up an internal CA, it is a huge
| pain to add the CA to browsers, since most browsers don't use
| the system trusted CAs.
| devrand wrote:
| Though most (all?) do support enterprise policies via GPO
| that would cover the vast majority of enterprise use cases.
| thayne wrote:
| which has to be managed separately for every combination of
| OS and browser. If all employees use chrome on windows,
| that's not too bad, but if you have employees using a
| variety of different setups, it it is more complicated to
| set up.
| foobarbazetc wrote:
| I know it's just another test, but the constant changes to the
| lock icon/indicators that a connection is secure are becoming
| annoying...
| pupppet wrote:
| > In particular, our research indicates that users often
| associate this icon with a site being trustworthy, when in fact
| it's only the connection that's secure.
|
| Never really thought about that, but I guess it's pretty obvious.
| I can totally see my folks downloading/buying god-knows-what from
| a site because they see that lock icon.
| cunthorpe wrote:
| They started realizing this when HTTPS was becoming common
| thanks to Let's Encrypt and slowly started removing any
| greenness and "Secure" label from the URL bar in favor of doing
| the opposite: marking _insecure_ websites in red.
|
| This last change is obvious and needed but was probably left as
| a last step because people have been taught to look for it at
| some point. Glad to see it gone, even just 'cause Safari puts
| it in the middle of the URL bar and I keep clicking on it by
| mistake. Hopefully they'll drop it to by 2024
| jeffbee wrote:
| Interesting that "Linux" is the platform with the lowest observed
| adoption of HTTPS ... implies some kind of bias in the way Linux
| users use Chrome. ChromeOS, which is also Linux but I assume not
| included in the data with the Linux label, has by far the highest
| fraction of HTTPS.
| beefman wrote:
| What about those of us who run websites with
|
| 1. No need of security whatever
|
| who
|
| 2. Don't want to fuck around with certificates
|
| ?
| yoursunny wrote:
| I hope HTTPS-First mode would become the default, so that the
| full page warning can finally convince my classmate to adopt
| HTTPS on their website that "does not contain any private info so
| it doesn't need encryption".
| machello13 wrote:
| Is it a web app or just a static site? I still haven't seen a
| good argument for why static sites (blogs, personal sites, etc.
| that process no user information) should implement HTTPS.
| jefftk wrote:
| Do you want ISPs or other intermediaries to be able to inject
| ads into static sites?
| kmeisthax wrote:
| Excluding things like zero-day exploits, the biggest problem
| with allowing _any_ unencrypted traffic is cache-poisoning.
|
| This was noticed when a Google engineer went on holiday, and
| stayed at a hotel with dodgy Wi-Fi that copypasted ad scripts
| into anything that looked like jQuery. Said engineer realized
| that his laptop was still getting hit with the hotel's ads
| for months afterwards, because it had managed to poison one
| of those "JavaScript CDNs" that a lot of other sites use.
|
| This is, of course, an attack - a hotel that can get an ad
| script onto arbitrary sites by rewriting one unencrypted
| request can also add a script that, say, siphons information
| off of any other site it got included into.
| r1ch wrote:
| Thankfully the impact of this is limited in modern browsers
| as the cache is partitioned by site.
| kmeisthax wrote:
| Which, incidentally, also removes the last fringe benefit
| of those free "JavaScript CDN" services. They are a
| strict net-negative now.
| Ajedi32 wrote:
| Sounds like Chrome is finally taking steps to combat that,
| as the post mentions they plan to "Restrict how, and for
| how long, Chrome stores site content provided over insecure
| connections"
|
| PoisonTap is a particularly good example of how devastating
| this type of attack can be:
| https://github.com/samyk/poisontap
| geofft wrote:
| I use HTTPS on my blog, which is a static website with no
| comments, because my blog contains information that I want
| people to be able to trust, and so I don't want an MITM to be
| able to modify it.
|
| There are a whole bunch of says that they can do that. The
| obvious way is that a lot of my blog is about programming,
| and so I have code on my blog people can copy/paste. If a
| MITM can modify that (perhaps by injecting something with
| font-size-zero), that directly harms my readers, and
| selfishly, that reflects poorly on me - it makes it look like
| I'm trying to harm my readers.
|
| I also have prose blog posts where I express advice or
| opinions. If I write about, say, security advice, and that
| advice has been modified to be bad, that also harms my
| readers and reflects poorly on me. Why would someone do that?
| I don't know, there are lots of trolls on the internet. More
| interestingly, I also write about my religious beliefs. If
| someone modifies a post to make me look like I'm one of the
| most egregiously bigoted people of my religion, that would
| also be harmful to my readers and reflect poorly on me, and
| the casual reader might not notice that the post is out of
| character, and there are a lot of people on the internet who
| are angry at my religion.
|
| Also, even if I didn't have any such information, a MITM
| could add a cryptominer or something to my blog - something
| that accesses no private information but still consumes my
| visitors' CPU and battery - would harm my readers and reflect
| poorly on me.
| a1371 wrote:
| As a whole https makes internet better for sure, but what's
| wrong with the classmate's argument in particular?
| kevincox wrote:
| - It is still revealing what content you browse. For example
| your ISP may be profiling you. (There are other leaks that
| reveal the domain to the ISP but hopefully those are slowly
| being removed as well).
|
| - A man-in-the-middle may replace your innocent content with
| something unpleasant. This is both bad for the viewer, and
| harms your reputation (even if it wasn't your fault).
| litoE wrote:
| My home network includes a router and several WiFi access points.
| They are managed through a browser, which means they have a
| built-in web server. I have them configured so they are only
| visible from the internal IP addresses and changed usernames and
| passwords from the built-in defaults, but there's no way to
| install a certificate in them, let alone force them to use https.
| So whenever I use Chrome to reconfigure one of these devices I
| get warnings of impending doom. A big PITA.
| jasonkester wrote:
| Can anybody suggest what might be the motivation for this? Beyond
| the silly "bad people might tamper with the cat picture you're
| shown" one that is always given? Chrome hates http with such a
| passion that there must be some evil motive behind it that I'm
| not seeing.
|
| Because they just keep making life more difficult for websites
| that don't need SSL.
|
| So now in addition to seeing a scary icon on the url bar with a
| scary message, my users are going to have to click past an
| interstitial banner just so they can visit a website and read
| silly travel stories. Chromium will try their best to convince
| them to leave, lest some nefarious agency on their home wifi
| substitute alternate silly travel stories that somehow cause them
| harm. In the 20 years the site has been live, I skeptical that
| this has happened often enough that we need to get Google
| involved.
|
| It's frustrating.
| nanis wrote:
| > Can anybody suggest what might be the motivation for this?
|
| The push for HTTPS everywhere started with HR4681[1] both of
| which were reactions to Snowden revelations.
|
| > Beyond the silly "bad people might tamper with the cat
| picture you're shown" one that is always given?
|
| Someone who is able to tamper with the cat picture you are
| seeing can also inject arbitrary code into your computer, so
| there is that.
|
| Also, thanks to the push for HTTPS everywhere, a large volume
| of traffic now goes through CloudFlare enabling them to do that
| on behalf of state actors etc (I am not claiming they do it,
| but it is kind of ironic that the least friction thing for me
| to enable HTTPS on a whole bunch of sites was to put a MITM ;-)
|
| Totally love CloudFlare BTW. The free level covers what I need.
| Still, it is ironic.
|
| [1]: https://www.nu42.com/2014/12/https-everywhere-and-
| hr4681.htm...
| joe5150 wrote:
| Mozilla has taken similar steps to encourage websites to
| implement HTTPS, and I can't say whether you believe they share
| Google's evil motivations, but it's a clear trend across
| browser vendors.
|
| Certificates are free now and not necessarily any more
| difficult to install and maintain than any of the other
| software you need to run even a basic website. It's something
| relatively simple I can do to ensure the integrity of the
| content I want people to look at, so why not?
| johnnyapol wrote:
| I don't know Google's motivation but frankly I welcome TLS
| everywhere on the public-facing web now that certs are free
| thanks to LetsEncrypt.
|
| For me, it comes down to two things:
|
| 1. Privacy. When I'm on non-private networks, its nice to have
| assurance that other people aren't able to get the specific
| contents of what I'm viewing.
|
| 2. ISP bad behavior. A number of ISPs have been doing things
| like injecting ads or other trackers into plain-HTTP sites.
| https://www.infoworld.com/article/2925839/code-injection-new...
| r1ch wrote:
| 99% of people if you tell them to go to website.com will type
| website.com into the address bar. This will send an unencrypted
| HTTP request on port 80, even if the site supports HTTPS. This
| initial navigation can be intercepted by a MITM and redirected,
| spoofed, whatever (coffee shop WiFi is a great example of where
| this could be dangerous). Making the default navigation use
| HTTPS negates this attack.
|
| As a small side bonus, it also reduces navigation latency by
| several RTTs, as there is no longer the need for a connection
| to port 80 HTTP that only always gets redirected to HTTPS.
| corentin88 wrote:
| Removing the lock icon is a very good idea. I'm not surprised
| that Chrome's team found out that only 11% of participants to a
| survey understood what it really means.
| izzytcp wrote:
| That means they should wait until 90% of them know what it
| means, before removing it.
| kevincox wrote:
| I don't see the logic here.
___________________________________________________________________
(page generated 2021-07-14 23:00 UTC)