[HN Gopher] The browsers are probably running the TLS show now
___________________________________________________________________
The browsers are probably running the TLS show now
Author : gdwatson
Score : 109 points
Date : 2020-03-09 13:47 UTC (9 hours ago)
(HTM) web link (utcc.utoronto.ca)
(TXT) w3m dump (utcc.utoronto.ca)
| rossdavidh wrote:
| It is difficult to find a group of companies less trusted to do
| the right thing than the major browsers (Apple, Google,
| Microsoft). However, the CAs qualifies, ironically perhaps, as
| less trusted.
| prepend wrote:
| Does certificate length really matter? It seems like other
| factors related to certificates are much more important than the
| ability for a cert to be stolen, reused, and not revoked.
| will4274 wrote:
| Cert revocation for the web is broken, which is why there's
| been so much emphasis on lifetime. Revocation checks are a
| privacy leak and reliability degradation and DoS vector, unless
| you use something like OCSP stapling, which fairly few sites
| do.
| dochtman wrote:
| Mozilla is starting to do CRLite, which should be an
| improvement here:
|
| https://blog.mozilla.org/security/2020/01/09/crlite-
| part-1-a...
| nullc wrote:
| Why is this an improvement? Has there been a rash of stolen
| certificates or domain name ownership changes? Is having a third
| party with a cert for a domain you're using for 12 months
| acceptable in a way that 2 years isn't?
|
| It would be nicer if certs could be issued with long lives but
| required a stapled revalidation with a short time span (daily?
| weekly?), which would be automatically issued at any time
| requested unless the certificate was revoked.
| moviuro wrote:
| > It would be nicer if certs could be issued with long lives
| but required a stapled revalidation with a short time span
| (daily? weekly?), which would be automatically issued at any
| time requested unless the certificate was revoked.
|
| That's called OCSP Must-Staple: see
| https://en.wikipedia.org/wiki/OCSP_stapling,
| https://github.com/acmesh-
| official/acme.sh/blob/d437d6fde95d...,
| https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deploym...
| hamandcheese wrote:
| How does that help vs simply having short lived certificates?
| nullc wrote:
| (re-)Validation costs. In theory, if it was just a "not
| revoked" signature, anyone could obtain it. No access to
| thorny private keys needed, etc.
| falcolas wrote:
| This is an unexpected (from someone outside the cert industry)
| development. I know for sure it will have some impact on servers
| I manage, since we typically purchase 2 year certs, and issue 5
| year certs internally.
|
| It's also been shown recently that not all companies are great at
| managing their certs, with notable shutdowns associated with
| expired certificates. Increasing the frequency of updating certs
| should be a good thing, but in practice I'm afraid that it will
| remain a manual project for some time to come.
| Avamander wrote:
| I don't think it's unexpected. Browsers are _the_ lifeblood of
| CAs.
|
| Unless CAs insert themselves more into the process of code
| signing, S/MIME, GPG or something like that. They will remain
| under the heavy influence of browsers.
| falcolas wrote:
| The move to 1 year is what was unexpected to me. Browsers
| taking over the rules around CAs, I agree that it's a natural
| expansion.
| Avamander wrote:
| Browsers did the same thing with Certificate Transparency
| earlier, unnoticed to many.
| Spivak wrote:
| I feel like this is a fairly narrow view of the situation. In
| theory the CA "System" ought to be much bigger than just web
| traffic since a globally distributed hierarchical database of
| certs is neat and could be used for all sorts of stuff.
|
| The fact that browsers have so much say in how the CAs operate
| that database makes me think that the public CA system is
| actually a wildly successful failure. If the public CA system has
| no other use than to allow someone to securely connect to one of
| a handful of web browsers then why all the fanfare over just
| having letting the companies stewarding the browsers run the show
| entirely?
| tialaramex wrote:
| A few things are going on.
|
| Firstly you often don't need a PKI, and when you do need a PKI
| (which as I said is less often than people think) you often
| don't need a public one.
|
| Take EMV ("Chip cards"). There's public key crypto securing
| your payment card transaction. There are multiple organisations
| involved. So we've got a PKI, but does it need to be a public
| PKI? Why not just let EMVco run everything, probably badly, and
| have them and their members (the banks and other big financial
| firms) eat it when inevitably they do a bad job? So that's what
| happens. If a CA in the EMV ecosystem does a bad job your bank
| will end up eating the cost of that, or maybe your country, the
| headline won't be "Obscure CA misissues certificate" it'll be
| "Huge Bank loses $500Bn in IT catastrophe" or something.
|
| Secondly, the thing a PKI does relies upon is a common naming
| scheme. The standard actually used in the Web PKI, X.509 was
| designed for a world with a global directory of everything, the
| X.500 global directory system. That directory does not exist.
| What common naming schemes are there that we'd want digital
| certificates for?
|
| The IETF published RFCs from the PKIX working group, defining
| how X.509 can be used for the Internet's names. That is, mostly
| ipAddresses, dnsNames, and emailAddresses.
|
| The Web PKI concerns itself de facto with the first two. You
| _could_ and some people do use IP addresses or DNS names in a
| context outside the Web PKI, but mostly they don 't. "Don't
| roll your own". Even the successor to TCP, QUIC, was re-
| designed to have it just envelop TLS and thus depend upon the
| Web PKI, rather than inventing a new shiny public key crypto
| technology and associated PKI.
|
| So the only use case we actually care about that didn't end up
| happening was email, S/MIME is what was attempted and... I have
| no doubt Thomas Ptacek can explain at considerable length how
| unlikely it is that anybody can get that to do what you'd
| expect it to do and deliver you any meaningful security if
| you're interested.
|
| It should definitely give you pause when you see a system which
| really seems like it could only be secured by a PKI and it
| isn't the Web PKI. Is it a private PKI? Who has oversight? Or
| are they just going through the motions and the security is
| illusory? The answer is the latter pretty often. Stakes are
| often thought to be very low until they aren't...
| inetknght wrote:
| > _In theory the CA "System" ought to be much bigger than just
| web traffic since a globally distributed hierarchical database
| of certs is neat and could be used for all sorts of stuff._
|
| Honestly I would love it if my password manager would also act
| as a personal certificate authority.
| tptacek wrote:
| People say this a lot. But where are the examples of all the
| "stuff" that would benefit by being linked into a single global
| PKI? Many of the most important public key crypto tools people
| actually use --- Signal, SSH and SSH CAs, U2F and WebAuthn,
| OAuth2 --- have little or no PKI at all.
| strbean wrote:
| I think the lack of standardization for a general purpose PKI
| is the biggest barrier, and the reason why Joe Schmo has no
| idea what a key pair is.
| tptacek wrote:
| You're not really answering my question. Assume the
| standardization falls into place, and it's all JSON instead
| of X.509 so that Javascript developers will actually use
| it. What gets better? What thing out there was just begging
| to be encrypted by a giant tree shared by the whole
| Internet?
| pvg wrote:
| _What gets better? What thing out there was just begging
| to be encrypted by a giant tree shared by the whole
| Internet?_
|
| The Nine Planes of the Internet would be connected.
| Nidhoggr, Dainn, Dvalinn, Duneyrr and Durathror would be
| in their ordained places, no longer roaming lost in
| endless Violation of the Layers.
| strbean wrote:
| It would also be much easier to transfer your data to
| Folkvangr / Valholl after you die a hero's death on the
| battlefield.
| strbean wrote:
| First thing that comes to mind is official emails from
| organizations to individuals. Wouldn't such a system
| basically squash most fishing?
| Avamander wrote:
| > But where are the examples of all the "stuff" that would
| benefit by being linked into a single global PKI?
|
| Estonia's national system and its e-services are a local
| example of a single central PKI. Provided services and
| systems seem to be far ahead of basically all other
| countries.
|
| Identity theft, identification, authentication, signing etc.
| have been solved for nearly two decades now and I have to say
| the way the rest of the world does stuff looks stone-age to
| me.
|
| For example I __loathe __how I 've been asked to do identity
| verification by foreign companies "send us a picture of your
| ID", WTF. Sentences like "Use SMS 2FA to protect your
| account", "e-mail us the bill" and "come to our office to
| sign {x}" make me shudder, it's absolutely dogs __*.
| pvg wrote:
| It's not an example of a global PKI and worse, Estonia had
| to invalidate/patch everyone's e-ids once already. A hassle
| somewhat mitigated by the fact that fewer people live in
| Estonia than in the Bronx.
| tptacek wrote:
| Thank Christ. The browsers have been far, far better stewards of
| the Web PKI than the CA/B Forum (at large) has been, and, in the
| main, the Web PKI exists to support browser security. That the
| major browser vendors are getting more muscular about their
| demands is a major shift: antitrust was a real concern that
| prevented a lot of important Web PKI stuff from happening sooner.
| But with Google and Mozilla breaking the largest CAs over
| documented misissuance, it's possible that concern has finally
| gone by the wayside.
| walrus01 wrote:
| Rather than browsers arbitrarily only trusting certain lengths of
| certs, of much greater concern to me is the number of root CAs
| trusted by every major browser, some of which are companies under
| the control of authoritarian states (Turkey, China).
|
| Go take a look at how many CAs your browser trusts, and tell me
| with a straight face that you absolutely trust every one of those
| CAs to always do the right thing.
|
| Certificate issuance transparency helps, but doesn't get rid of
| the fundamental issue.
| advisedwang wrote:
| There's also Certificate Authority Authorization DNS records
| (checked by CA so defends against abusive CSRs, but not an
| abusive CA).
| bogomipz wrote:
| >"Certificate issuance transparency helps ..."
|
| Could you elaborate on what transparency you are referring to
| here? How does it help with the amount of root CAs trusted by
| the browser? Thanks.
| 0x0 wrote:
| Certificate Transparency means SSL certs must have been
| logged to public CT log databases to be considered valid.
| This ensures that any monkey business MITMing with rogue
| certificates will be detected quickly, either by site owners
| seeing unknown certs for their sites in the log, or browsers
| rejecting unlogged certs.
|
| http://www.certificate-transparency.org/home
| tialaramex wrote:
| Two related things are happening here, and a third thing
| isn't actually happening today but is an active subject of
| research.
|
| 1. All the trusted CAs log either all the certificates they
| issue or the vast majority of certificates intended for use
| on the public Internet. They do this because it's a good
| idea, and (as we'll see in #2) because it makes commercial
| sense. The effect is that if you have a way to trick a CA
| into issuing something that shouldn't exist, or if they
| just issue it through the usual human fallibility (e.g. an
| operator fat fingers something at a console) researchers
| can see it, the same way they'd see if your Senator doesn't
| bother attending Congress - it's a matter of public record.
|
| 2. Google's Chrome, and later Apple's Safari require SCTs
| (Signed Certificate Timestamps) from logs before they
| accept newer certificates. The cheap easy way to arrange
| this is to log "pre-certificates" which get you valid SCTs
| and then you bake those inside the real certificate given
| to a subscriber. If you use Let's Encrypt, this is how SCTs
| got inside all your certificates, no extra work for you.
| There are fancier options that let you get a certificate
| and then obtain SCTs later separately, but they're rather
| niche. This means if you can obtain an apparently valid
| certificate but only a new enough one (thus after enough
| time in the future, any certificate) but no SCTs for it, it
| won't be valid in those browsers. The logs aren't supposed
| to give out an SCT without logging the certificate. So now
| an attacker needs to either log their bogus certificate (if
| they can) and show it to the world, or corrupt the logs
| too, a big ask on top of whatever attack they've done to
| trick or corrupt the CA issuer or bypass them.
|
| 3. Eventually the intention is a Gossip protocol. The idea
| here is, when you browser sees an SCT we should like to
| verify that the associated certificate was really logged
| irrevocably for everybody to see. But we'd like not to undo
| your privacy in the process. You don't want to tell
| everybody "Hey I like Balloon Porn" but you'd ideally like
| to be sure the certificate on your Balloon Porn website is
| seen in the logs by everybody, not just a special version
| of the log shown only to you and six other people under
| investigation for liking Balloon Porn. Figuring out the
| best way to approach this is an active research topic.
| wnoise wrote:
| Wouldn't it be nice if you could have certs signed by multiple
| CAs, so detrusting bad CAs would be easier without wrecking as
| much stuff?
| drdaeman wrote:
| TLSv1.3 removed the requirement on the certificate ordering.
| I haven't tried but I believe you can supply multiple
| certificates (and chains) in there.
| emilecantin wrote:
| There's nothing keeping you from getting multiple certs,
| signed by different CAs, and switching as soon as there's an
| issue with one of them.
|
| Of course, you'd have to do the switching manually.
| riobard wrote:
| Was there any proposal to limit which root CAs can sign what
| TLDs? Or is DANE still a thing?
| tptacek wrote:
| It's a thing in that there are recordsets you can create to
| implement DANE for your zone, and software you can install
| that will validate those records. It is not a thing in that
| no mainstream browser will look at DANE, and in that
| virtually no popular sites (especially in the technology
| industry) use DANE.
|
| DANE is a dead letter standard.
| riobard wrote:
| Are there any viable alternatives to DANE, or is this a
| dead end in general and we're stuck with CA forever?
| duskwuff wrote:
| CAA, which many CAs (including Let's Encrypt) already
| use:
|
| https://en.wikipedia.org/wiki/DNS_Certification_Authority
| _Au...
| riobard wrote:
| It looks like CAA does not prevent bad CAs at all? A
| rogue CA can just skip CAA altogether, no?
| crote wrote:
| Theoretically, a client could also query the record and
| check it against the certificate presented. That would
| basically be the same as a DANE CA constraint.
|
| I'm not aware of anyone actually doing this, though.
| Certificate Transparency requirements are probably enough
| to prevent any CA from attempting to cheat with CAA.
| tialaramex wrote:
| Don't do this. CAA is not "This is the list of CAs that
| are trustworthy for this domain".
|
| CAA is "This is the list of CAs that can _issue_ for this
| domain right at this precise moment ".
|
| If you aren't a CA you should only be looking at CAA
| either to debug a weird problem, out of curiosity or for
| some research purpose. Do not use it to make security
| decisions if you are not a CA.
| JoachimSchipper wrote:
| Rogue CAs can do almost anything, _but_ the browsers will
| kill any CA that is found to be (repeatedly) mis-issuing.
| And checking the CAA has apparently been in the CA
| /Browser Forum Baseline Requirements since 2017.
|
| That said, LetsEncrypt just had a nasty bug around CAA
| checking, and ended up not quite revoking all
| certificates for which insufficient checks had been
| executed:
| https://community.letsencrypt.org/t/2020-02-29-caa-
| recheckin....
| kodablah wrote:
| > Certificate issuance transparency helps, but doesn't get rid
| of the fundamental issue.
|
| I think the real innovation in transparency will be client
| side. I have been wanting to develop a "root CA" hit counter
| that tracked locally which of the sites you visit used which
| CA. You could say the logical addition from there is to allow
| users to disable unused CAs (or do it automatically when
| unused) and have a opt-in when a disabled one is used, but I
| think that's too much. Just a client-side plugin to let me see
| which CA is used and keep track alongside history (i.e. not in
| incognito) would be nice.
|
| I am waiting for this Chromium issue to implement such a thing:
| https://bugs.chromium.org/p/chromium/issues/detail?id=628819
| (looks already done in FF)
| tialaramex wrote:
| Yes, the Firefox plug-in "Certainly Something" uses the
| equivalent APIs in Firefox and works today, giving back a
| nicer version of their old "View certificate" UI only to the
| fraction of people who care, rather than weighing down the
| actual Firefox browser with more and more X.509 features most
| users will never need.
|
| You probably should not encourage lay users to disable CAs
| they aren't using, it's like those plastic "child safety"
| plug inserts in the UK - kids already can't actually do the
| thing the insert pretends to prevent, safety shutters
| mandated by law in your power sockets keep tiny fingers out
| of the live power - but the plastic insert is exactly the
| perfect shape for a kid to defeat the safety protection and
| electrocute themselves.
| saber6 wrote:
| > You probably should not encourage lay users to disable
| CAs they aren't using, it's like those plastic "child
| safety" plug inserts in the UK - kids already can't
| actually do the thing the insert pretends to prevent,
| safety shutters mandated by law in your power sockets keep
| tiny fingers out of the live power - but the plastic insert
| is exactly the perfect shape for a kid to defeat the safety
| protection and electrocute themselves.
|
| Your analogy is unnecessary. This is simply a case of
| determining which issuing authorities you want to trust. Do
| I want to trust ones in China? No. That's not racist by the
| way.
| evilpie wrote:
| Since Firefox 72, the built-in certificate viewer actual
| reuses most of the JavaScript code from "Certainly
| Something". So the extension isn't strictly necessary
| anymore.
| tialaramex wrote:
| Huh. I hadn't looked until now but you are 100% correct.
| What a strange choice.
| wnevets wrote:
| infamously the hong kong post office is/was a trusted CA
|
| https://bugzilla.mozilla.org/show_bug.cgi?id=373537
| Dahoon wrote:
| What's wrong with that? Is it worse than Comodo?
| computerfriend wrote:
| What's infamous about it?
| cpeterso wrote:
| More infamous is the request to add the root certificate
| for "Honest Achmed's Used Cars and Certificates":
|
| https://bugzilla.mozilla.org/show_bug.cgi?id=647959
| Fnoord wrote:
| I guess because it is an unusual relatively small entity
| who's position as a CA is unusual. Plus, without
| certificate pinning [ie. before HSTS] you don't want rogue
| CAs.
| 0x0 wrote:
| HSTS has nothing to do with pinning, you're probably
| thinking of the deprecated HPKP
| Avamander wrote:
| I've long wished for a browser extension that did DNSSEC and
| DANE validation and displayed which country's CA signed the
| current cert.
|
| CT helps somewhat, but given that Firefox doesn't enforce it
| leaves a lot of people vulnerable.
| tptacek wrote:
| That browser extension exists, or at least it used to. Of
| course, you run aground of the fact that nobody signs their
| zones (other than European domains whose registrars sign them
| automatically, which is, when you think about it, just
| theater).
|
| I don't know what you mean by "Firefox doesn't enforce [CT]".
| Mozilla has been instrumental in dis-trusting misissuing CAs.
| garrettr_ wrote:
| > I don't know what you mean by "Firefox doesn't enforce
| [CT]".
|
| They mean Firefox, unlike Chrome and Safari, doesn't
| require proof of inclusion in a CT log for recently issued
| TLS certificates to be considered valid.
|
| Source: https://developer.mozilla.org/en-
| US/docs/Web/Security/Certif....
| alwillis wrote:
| The latest survey of 250 million zones [1] shows that
| 10,787,502 zones are DNSSEC signed. And that number
| continues to increase steadily.
|
| [1]: https://stats.dnssec-tools.org/#summary
| tialaramex wrote:
| Mozilla has lots of policy but Firefox has very little
| policy enforcement. This is important for practical reasons
| I explained only the other day.
|
| For example Firefox doesn't check for SCTs so if you show
| my Firefox an apparently brand new certificate for which
| there are no SCTs (because maybe it's actually bogus) it
| will carry on as if nothing happened.
|
| It also doesn't check validity periods. If you show Firefox
| a certificate from Let's Encrypt claiming notBefore
| 1986-03-02 and notAfter 2024-09-16 it considers that seems
| fine, never mind that the Web PKI didn't exist in 1986 or
| that nobody is allowed to issue leaf certificates that last
| almost 40 years - it doesn't care about that.
| tptacek wrote:
| I think we're generally on a trajectory towards addressing the
| fundamental issue --- a few major firms will implement free
| certificates, like LetsEncrypt and ACM, and the industry will
| consolidate around them. And browsers will get stricter about
| transparency requirements for the oddball CAs. But it seems
| like we're definitely going to salami slice our way out of this
| problem.
| amluto wrote:
| I have absolutely no problem trusting a Turkish CA for a
| Turkish domain. I don't want to trust it for .com.
|
| I cannot fathom why browsers can't pull this off.
| tialaramex wrote:
| They can, and Mozilla (in Firefox) does:
|
| https://wiki.mozilla.org/CA/Additional_Trust_Changes
|
| > The Turkish Government CA is name-constrained to a set of
| turkish toplevel domains - that is, .gov.tr, .k12.tr,
| .pol.tr, .mil.tr, .tsk.tr, .kep.tr, .bel.tr, .edu.tr and
| .org.tr.
| londons_explore wrote:
| Why not constrain it to ".tr"?
| HappyDreamer wrote:
| What if there was a country flag or something, indicating
| where the CA was located -- in which country /
| jurisdiction?
|
| Then, let's say it's in China or Turkey or Kazakhstan, etc
| etc, then I would know that the politicians/police there
| might have decided to man-in-the-middle listen to anything
| I type into that website.
|
| And what if there was a Freedom of Press index number (or
| sth like that) next to this flag? (because who can remember
| all flags)
| drdaeman wrote:
| Browser vendors are moving in the exactly opposite
| direction, removing visibility into any technical
| information beyond the green padlock icon.
|
| Today, it takes a few more clicks to see the detailed
| certificate information (let alone the CA name), than it
| used to be.
| gsich wrote:
| Don't expect too much. Browsers can't even display
| punycode to avoid being scammed.
| Normal_gaussian wrote:
| A plugin is your best bet. The flag is one thing, but the
| nature of the index concept ensures it will be suitable
| for only specific audiences.
|
| That is the validity never mind the importance of such
| metrics is a position of opinion.
| tialaramex wrote:
| You absolutely can build a plugin for Firefox (and
| Chrome? Maybe? Sounds like some APIs needed are not
| finished) to add this UI feature for people who want it.
|
| Experience shows that if _everybody_ wants a UI feature
| from a plug-in it won 't take long until the people you
| were plugging into implement it natively and you can
| choose to take that as praise or shake your fist at them
| for "stealing". I recommend the former.
|
| But I doubt your new "Freedom of the Press of the CA
| issuer of this site" UI will be very popular because it's
| not at all obvious what anybody can do with that
| information or how to even interpret it.
| gpm wrote:
| Well, for one thing, if the lock on google.com starts
| showing a chinese flag I think everyone who notices would
| know to be suspicious.
| Cpoll wrote:
| It might lead to a false sense of security.
|
| I don't think it'd be overkill to send a request to all 52
| CAs (and fail if you get conflicting answers). Then the most
| a trusted CA could do is DoS some sites.
| tialaramex wrote:
| > Go take a look at how many CAs your browser trusts, and tell
| me with a straight face that you absolutely trust every one of
| those CAs to always do the right thing.
|
| OK. There are 52 of them, listed here: https://ccadb-
| public.secure.force.com/mozilla/CAInformationR... although
| perhaps don't bang on Salesforce's poor server, it seems like
| for some reason this isn't trivial for them to do?
|
| I do in some sense trust them to always do the right thing,
| but, as the saying goes "Trust but verify". As well as trusting
| them I also pay attention to what I see and other people see
| and press them to do better when they fall short.
|
| I actually think their record has been fairly good, and is
| gradually improving. It could always be better, but on the
| whole what I see from CAs is exactly what I'd expect from
| humans generally, they are lazy and incompetent and so we have
| to design things to take that into account. I'd expect no more
| from any of us.
| ori_b wrote:
| > _As well as trusting them I also pay attention to what I
| see and other people see and press them to do better when
| they fall short._
|
| Can you give an example of how you have personally pressed
| them and how they responded?
| tialaramex wrote:
| Sure, after Let's Encrypt posted initially at the end of
| February about their uh, bug, I responded in part:
|
| > That is, how many certificates were really issued to
| multiple FQDNs (if a single FQDN the bug described has no
| effect) more than 8 hours after initial correct CAA checks
| ? Intuitively this should be almost none, but intuitions
| can be misleading.
|
| Jacob responded by saying that they were "working on this
| analysis today" although in fact the next we heard was a
| complete list of arguably misissued certificates a few days
| later in an announcement that was linked from Hacker News
| and which you've hopefully seen.
|
| I wrote (in that Hacker News thread) that this was one way
| to answer my question :D
| Santosh83 wrote:
| On the one hand we argue the Internet should be global and not
| get Balkanized and on the other hand we arbitrarily select
| certain countries to place lesser or higher trust in. Someone
| in China could legitimately have a similar low level of trust
| for US root certs and he/she would not be far wrong given that
| NSLs can gag companies into complying with arbitrary dictums
| that no one ever knows about.
| jopsen wrote:
| > Someone in China could legitimately have a similar low
| level of trust for US root certs...
|
| I love bashing America as much as the next guy, but equating
| it to China in terms of trust is not fair.
| vbezhenar wrote:
| I live in Kazakhstan and I absolutely don't trust US. I
| don't fully trust Kazakhstani government either, but at
| least I know that they won't act hostile to me. I'm not
| removing US CAs, because it would be absurd, but I'm
| actually pretty angry at Firefox blacklisting some KZ
| certificates without my permission (and even without clear
| way to manually trust it again).
|
| IMO software must respect every country and let government
| to act on their citizens as they want, even if some US guy
| thinks that it's not OK. It's not really his business.
| bananabreakfast wrote:
| That's some nice whataboutism you got there
| tuxracer wrote:
| The risk of the communication being compromised isn't
| necessarily the sole concern. There are also varying levels
| of consequences for various types of communication for
| different countries. When it comes to a country that has
| developed extensive censorship mechanisms and it's casually
| accepted that one could face a visit from the police or
| jailed for criticizing its leader or party it doesn't seem
| completely arbitrary to have some additional concern when it
| comes to that country possibly compromising your
| communication.
| chongli wrote:
| The original hacker dream of the internet was that it would
| break down borders and open up the free flow of information.
| Now that non-hacker types (politicians and bureaucrats,
| mainly) have had access for a few decades, they've realized
| how powerful a tool it is for empowering their authoritarian
| impulses.
|
| Call me cynical but I think it's only a matter of time before
| the internet becomes totally Balkanized. Heck, it's almost
| there right now.
| gowld wrote:
| Don't confuse a "country" with a "government". The Internet
| is global, but that doesn't mean I trust every person on it.
| That's why we have spam filters and block lists and cert
| trust lists.
| Dahoon wrote:
| > (Turkey, China)
|
| I don't get why it is always authoritarian states that is
| pointed fingers at when history clearly shows us that it isn't
| authoritarian states that are the biggest problem but so-called
| democratic states. I get why one would dislike authoritarian
| states (I do too) but the smart move is to look at who history
| tells us not to trust - not just believing the bogyman is
| coming.
| quotemstr wrote:
| And the browsers, in turn, are controlled by a few big tech
| companies. Is it a good idea to give those companies control over
| the trust architecture of the internet? What happens if you get
| on tech's persona non grata list? Do you not get to use the PKI?
___________________________________________________________________
(page generated 2020-03-09 23:00 UTC)