[nSLUG] Wikipedia changes/limits protocols?
George N. White III
gnwiii at gmail.com
Wed Jul 15 08:31:51 ADT 2015
On Wed, Jul 15, 2015 at 3:14 AM, Mike Spencer <mspencer at tallships.ca> wrote:
> George N. White III wrote:
> > If you only encrypt traffic to one site that tells an eavesdropper
> > something about your activities.
> > If all internet traffic is strongly encrypted that makes it harder
> > for eavesdroppers to identify "interesting" traffic.
> Hypothetically (I don't bank by net), suppose I only encrypt traffic
> to TD Bank. Anyone who can eavesdrop on my traffic will infer that
> such a connection relates to money. Similar, mutatis mutandis, for,
> say, encrypted connection to travel (going to travel
> sometime?) or theatre (spending some evening out?) ticket sales.
> HTTPS doesn't conceal the destination of packets.
If everyone uses https all the tie then the use of https is no longer a
flag for potentially "interesting" packets.
> > https also increases the chances that your are connected with the
> > real wikipedia rather than some version your government created to
> > hide articles they don't like or that they consider to violate some
> > rules.
> Right. By all means, *allow* and support HTTPS connections.
> > I use the EFF's HTTPS Everywhere browser extension, and have noticed
> > an increase in transient glitches. A paranoid would think either a)
> > someone is DOSing https to discourage wider adoption, or b) someone
> > doing deep packet inspection and running into resource limits as the
> > https traffic volumes increase.
> Do you mean, unpacking the IP packets and attempting to decrypt the
Until recently, many https connections used weak "export" level
encryption whchi existed to facilitate eavesdropping by NSA but
by now is likely open to many governments and criminals. There
are still lots of complaints about being forced to upgrade browsers
and servers to use stronger encryptions
Some time ago I posted about a little experiment I did that proved
> some entity in an email path was unpacking email, undoing base64
> encoding, then re-encoding before delivery. I'm more paranoid about
> email surveillance than web, but perhaps only because I use hardly any
> of the Ajax/web 2.0 services. I keep meaning to beat up gpg RSN but then,
> most of my email correspondents are doing well to do email at all,
> never mind getting them to implement encryption.
Same here. I try to avoid putting anything in email that I wouldn't want
posted on some web page, but you can't guard against people cutting
and pasting to change the meaning of your words (climate-gate).
> Until I've bitten the bullet and read a lot of hard stuff that I
> haven't read, I might have a wholly wrong idea. I'm inclined to think
> that the weak point in the HTTPS business is the certificates (which,
> admittedly, I don't understand.) They're issued by, now, any of a
> large number of corporate entities. Your browser (not *you*, doing
> your homework) has to have verification data for current authorized
> certs/issuers including revocations. The issuing entities are
> themselves enticing targets; if you penetrate or co-opt them, you get
> widespread "authority", not just one individual or transaction. And
> there have been several instances now of fraudulent, penetrated or
> attack-vulnerable cert mechanisms. (That's intentional vague because I
> forget the details.) I've read Schneier's *other* book, too, the one
> on trust and it wasn't very convincing wrt corporate entities and
> government agencies.
Some of the recent bugs involved mishandling of certificates so bad actors
didn't even need access to a real certificate authority.
> What "transient glitches" are you seeing?
Words like "can't connect securely ...". Problems with certificates for
of Canada sites and large corporations like Apple and Helly-Hansen. Https
Everywhere is an uphill battle when so many sites have outdated or
George N. White III <aa056 at chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nSLUG