
The Downside of Encrypting Everything: Virus-Filled Ads Are Harder to Track - frostmatthew
http://motherboard.vice.com/read/the-downside-of-encrypting-everything-virus-filled-ads-are-harder-to-track
======
duskwuff
Er...

I'm not sure I see how having ad traffic travel over HTTPS is a problem here.
Malware researchers deal with HTTPS all the time. It's not some sort of
insurmountable barrier -- the content is all available to a browser, after
all.

~~~
adricnet
The content is available after it is decrypted in a browser on a _single_
host. If the streams are inspectable by network defenses they can be inspected
at much more feasible scale allowing one device to protect 10,000s of hosts
from the same malware-laden ad. The alternative is to try and deliver
protection to 10,000 browsers, and somehow keep them synchronized which is
just so much harder and expensive. Or you could make the host operating
system, apps, and the browser resistant to exploitation...

It's not that encrypting secrets is bad (and sessions are secrets). It's that
encrypting everything without looking at what you gain and lose is poor
engineering and it all seems to be politicized somehow (camps, factions,
dogma..) with HTTPS-only being pushed as the answer to one security problem
(confidentiality vs active eavesdroppers) at the expense of existing solutions
to other problems, including integrity (please don't compromise my hosts),
availability (I cannot use recent browsers to admin my equipment because they
ban self-signed certs but trust 100+ CAs) and non-repudiation (where did the
malware come from?).

... speaking as someone who studies malware analysis.

Cheers, adric

------
facetube
IMO, look for increasing pressure on CAs to unilaterally revoke certificates
issued to known malware networks.

~~~
dogma1138
That won't happen, if anything SSL cert's are easier to get now than ever and
with projects like letsencrypt.org it will become even easier.

Also many of the malicious adds do not come from malware networks they come
from all major ad networks including Google's.

You have ads exploiting zero day vulnerabilities in Flash and browsers that
not easy to detect, and with the amount of syndication in ad networks you
can't effectively blacklist or revoke them.

One of the downsides to this whole "letsencrypt" movement and CA's from less
"organized" countries being accepted by major browsers and clients is that you
will have much more failures in security.

SSL was designed around high level of trust and that trust worthy SSL
certificates will not be easy to come by, this is why they used to cost so
much there was actual inspection and you would get fraud insurance for quite
high amounts. Today i won't be surprised if you could get a Google.com cert
from some low tier CA in the Philippines which automates the process and it
will be valid on large amount of devices.

We need a better verification system for SSL and actual policing of
certificates including integrating it into DNS, if i ask for Google.com i
should get a "cert" entry from the DNS server just as i get the A entry for
it, and i don't understand why this isn't the case yet.

~~~
themartorana
Because the main thrust of HTTPS at this point is regaining some privacy from
snooping governmental organizations more than it is building a trust chain.

~~~
dogma1138
So having a chaotic system in which SSL certificates are easy to near trivial
to get and hence spoof makes it harder for organizations to spy on you?

~~~
Karunamon
In a manner of speaking. Even a self signed certificate prevents you from
passive eavesdropping and traffic injection (a thing we _know_ the US
government is doing _right now_ ) if not an an active man in the middle
(something which may or may not be happening to you on the plain HTTP
connections you use every day)

~~~
dogma1138
Passive eavesdropping yes, injection nope since it's not passive to begin with
and unless you can explicitly verify it it's pretty useless. SSL works because
we assume that people can't issue certificates for websites that they do not
control which isn't the case.

~~~
pdkl95
MitM on a self-signed certificates costs more than QUANTUM-style packet races.
Please, stop trying to keep the internet in plaintext.

~~~
dogma1138
I'm not trying to keep the internet in plain text, I'm trying to keep the
internet a place where i can trust the certificates and not having to worry
about a CA in china issuing certificates for the sites i visit because they
can be CBA to check.

An attack against a self signed cert may cost more then what ever but that
wasn't what we were talking about initially either.

If you can MITM which they can and can get cheap valid certificates it's game
over.

And while the NSA might be able to get certificates no matter the case, people
have managed to buy certificates for domains they do not own multiple times
now.

Which puts the ability to MITM real world SSL sessions in the hands of
individuals.

~~~
pdkl95
> I'm trying to keep the internet a place where i can trust the certificates

That ship sailed a long time ago. While hierarchical PKI has always been a
flawed concept (I find it unlikely that you actually trust all of the
organizations that firefox/etc ship as trusted roots). Even if you did, as you
aid, these "authorities" have signed improper certs.

Trying to patch holes in this failed system (such as revoking those improper
certs) is yet another foolish attempt to enumerate badness[1]. If you want
authentication, you need do your own chain-of-trust instead of assuming ~100
cert authorities will do that for you.

> Which puts the ability to MITM real world SSL sessions in the hands of
> individuals.

So we should keep the world in plaintext (by not allowing self signed certs)?

Quite a few people besides the NSA already[2] MITM connections. My point is
that we absolutely need to raise those costs. Even with the NSA, just because
they have the capability to do something doesn't mean you should give up.
_Make_ the do the extra work of a MitM attck (even if probably a small amount
of extra work in the case of the NSA).

Add another categorization if you want. Nobody said you have to treat self-
signed certs as secure, just that they _need to be used_. Privacy from
eavesdroppers and authentication are separate goals.

[1]
[http://www.ranum.com/security/computer_security/editorials/d...](http://www.ranum.com/security/computer_security/editorials/dumb/)

[2]
[https://projectbullrun.org/surveillance/2015/video-2015.html...](https://projectbullrun.org/surveillance/2015/video-2015.html#bernstein)

~~~
dogma1138
I think we are mostly in agreement, but the problem is that if the attacker
can perform a MITM attack then a self signed certificate unless it's
explicitly verified is worth less.

I've said that we need to add additional levels of trust to the current
PKI/SSL cert system preferably adding DNS records with the hash of the
certificates and enforcing DNSSec globally this isn't the best solution but
it's just enough of an easy hack that it will work for a good while.

What i do not want to see is people thinking that if we just spam SSL certs
and stick them on everything it will some how help us, this is the classical
definition of security theater.

When cost reduction isn't sufficient to thwart any effective surveillance, and
worse using self signed certs trains people to just click accept, and free SSL
certificates make it easier to gain valid certificates in a fraudulent manner
things will only become worse not better.

While it's true that authentication and encryption are separate domains with
how TLS/SSL is implemented currently they are tied by the hip, if you can't
trust the authentication part of SSL the encryption part becomes meaningless
to all but the most primitive types of passive sniffing.

If you want to separate them then lets kill TLS all together since PKI for the
most part have failed, we can use other pure key exchange mechanism like well
implemented DH without all the certificate nonsense.

~~~
Karunamon
_and worse using self signed certs trains people to just click accept_

This is a thing that happens right here, right now. We treat all of the
following things as equivalent big scary warnings from the browser regardless
of how bad they are or what the impact on security actually is.

    
    
        * Expiration date d+1day (security impact: NIL)
        * Name doesn't match the cert
        * CA not trusted
        * Certificate is self-signed
        * Certificate was generated using old/broken crypto
    

Weve've got a couple decades of retraining to do because of this boneheaded,
"wolf-crying" design.

~~~
dogma1138

        * Expiration date d+1day (security impact: NIL) > not much impact unless the certificate age is tied to the time it might take some one to refactor a key
        * Name doesn't match the cert > Can't trust that you communicating with the correct party, worth as much as plain text to me
        * CA not trusted > Unless you can explicitly verity the end certificate and the chain = plain text to me
        * Certificate is self-signed > same as the above
        * Certificate was generated using old/broken crypto > depending on the exact issue government agencies will most likely be able to break the encryption, if it's more easy attacks like BEAST or CRIME so can resourceful non-governmental organizations and individuals.
    

This isn't just crying wolf we need a new and better system, one that ensures
that the key exchange is secure, and one that ensures that who ever you
speaking too is the actual intended precipitant and not a system which
currently if one of those fails both fail, and more often than not can easily
fail on both on it's own out of the gate.

~~~
Karunamon
It is exactly crying wolf because AFAIK, okay, cert expiration - you don't
have to rekey when you go get a new one, you just get a new one. The benefit
seems to be commercial, rather than technical.

Name doesn't match: I've encountered a legitimate (as opposed to an obvious
misconfiguration) error along these lines precisely zero times in well over a
decade.

CA untrusted: CA trust is worthless - the browser doesnt differentiate between
"the person who holds the cert had control of the domain when we generated it"
and "we made sure this person exists and checked their identity". (Unless you
jump into the total scam that is EV certs...)

Would you kindly stop banging on about "As good as plain text?". because as
has been explained to you _ad nauseum_ , in the worst case it becomes you vs
one attacker who holds the key to the bogus cert, instead of you vs anyone on
the local wifi network. The number of attackers is unbounded in the latter
case, QED, it is strictly a better security posture.

SSL as it exists today is fine for keeping _a_ hacker out of your connection.
It was not designed nor implemented for a post-Snowden world.

------
Khaine
If we block ads, there isn't a problem

~~~
ised
If sites start moving to HTTP/2, is it true the untrustworthy code can be
inserted into the same stream as the "content"?

Everything could be coming from the same domain/IP? This might make blocking
ads and tracking more complicated?

My solution as HTTPS spreads is to MITM my own connections so I can see what
is being sent and received over the wire. As the article says, it is a PITA.
But it is necessary.

