[whatwg] whatwg Digest, Vol 82, Issue 10

On Wed, Jan 5, 2011 at 1:34 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> I wouldn't. ?Just because a user trusts some particular entity to know
> exactly where they are, doesn't mean they trust their stalker with that
> information. ?I picked geolocation specifically, because that involves an
> irrevocable surrender of personal information, not just annoyance like
> disabling the context menu.

It's not really irrevocable.  A MITM only has access to the info as
long as he's conducting the MITM.  As soon as the attack ends, the
attacker stops getting info.  Moreover, anyone who's intercepting your
Internet traffic could probably make a good guess at your location
anyway, such as by looking up your IP address or triangulating
latency.  So I don't think that it's such a big deal if MITMs can
compromise geolocation, relatively speaking.

On Wed, Jan 5, 2011 at 11:07 AM, Roger H?gensen <rescator at emsai.net> wrote:
> Considering the fact that StartCOM ( https://www.startssl.com/ ) offers free
> domain based certificates that all major browsers support now (IE/Microsoft
> was a bit slow on this initially),
> there is no longer any excuse not to make use of https for downloading
> "securely" or logging in/registering (forums etc), or using "secure" web
> apps.

There are lots of reasons.  Getting a cert is only the start.  Other
problems with HTTPS include:

* You can typically only serve one domain per IP address, unless you
can set up SNI (do all browsers support that yet?).  This is a blocker
issue for sites that are too small to have their own IPv4 address,
like at a big shared web host.
* Every connection involves extra round-trips, which hurts page response time.
* If your cert expires or you misconfigure the site something else
goes wrong, all your users get scary error messages.  In some cases
the browser will even refuse to let them proceed at all.  (Chrome does
this for revoked certificates and I've run into it a couple of times.
Of course, I wasn't submitting sensitive information to the site, so I
just used another browser.)

Overall, HTTPS in practice is fragile and a pain to set up.  These
problems mean that it's common to see scary errors due to
misconfiguration on even extremely large sites, like
<https://amazon.com/>.  It's just not worth it for most people.  Which
is a shame, but there you have it.

On Wed, Jan 5, 2011 at 11:29 AM, Roger H?gensen <rescator at emsai.net> wrote:
> A hash (any hash in fact, even "secure" ones) can only guarantee that two
> pieces of data are different!
> A hash can NEVER guarantee that two pieces of data are the same, this is
> impossible.

It's logically impossible, but that doesn't mean it's computationally
impossible.  Whether a hashing algorithm exists such that no efficient
algorithm can find a collision with non-negligible probability is, as
far as I know, an open question.  In practice, hash functions such as
SHA256 can be regarded as secure for the present time -- if there are
collisions in this sort of thing, a lot of stuff will break.  Like
HTTPS, as it happens (we've already seen some fallout from MD5
collisions).

Received on Wednesday, 5 January 2011 15:54:52 UTC