Q&A Why security suites use an insecure connection?

Chakuz

Level 1
Jan 22, 2020
12
Hello,
first of all sorry for my bad school english.

I have tested a few antivirus programs (Eset, Panda, F-Secure, Kaspersky) over the past few days and have realized that a lot of traffic (signature updates etc.) is downloaded via an unsecured connection (HTTP).
Can anyone explain why a security provider will still be using their software over an insecure channel in year 2020?

The only ones who worked exemplary were GDATA, Emsisoft and WD- almost all traffic is encrypted using SSL ...

Best regards,
Chakuz
 
Last edited:

Vitali Ortzi

Level 21
Verified
Dec 12, 2016
1,000
Hello,
first of all sorry for my bad school english.

I have tested a few antivirus programs (Eset, Panda, F-Secure, Kaspersky) over the past few days and have realized that a lot of traffic (signature updates etc.) is downloaded via an unsecured connection (HTTP).
Can anyone explain why a security provider will still be using their software over an insecure channel in year 2020?

The only ones who worked exemplary were GDATA, Emsisoft and WD- almost all traffic is encrypted using SSL ...

Best regards,
Chakuz
It's because companies don't give a about consumer products.

Proof most of those companies actually force secure connection by default in the Enterprise grade products.
 

Chakuz

Level 1
Jan 22, 2020
12
In my opinion, they should not be sold as security software.

I think you should be able to expect in 2020 that your "security software" will download the signatures from a SSL-protected source. No matter whether it's an enterprise or a consumer. Just my 2 cents...

I will test other programs like Norton, TrendMicro etc.
 

TairikuOkami

Level 30
Verified
Content Creator
May 13, 2017
1,907
Lead by an example and since Microsoft does it, it is considered OK. Anyway, the overall cost is high, whether is the performance or the price.
 

MacDefender

Level 14
Verified
Oct 13, 2019
652
I assume one potential reason is that plain HTTP signature updates result in more cacheability if you still run a legacy Squid or other caching proxy server as a way of reducing bandwidth use.

Hopefully AV suites perform signature validation on their signatures, right? It doesn't matter if you transport the updates over plain HTTP as long as the client properly validates them.
 

Chakuz

Level 1
Jan 22, 2020
12
Hopefully AV suites perform signature validation on their signatures, right? It doesn't matter if you transport the updates over plain HTTP as long as the client properly validates them.
Almost right.
But if the software also passes data unencrypted that is worth protecting in Europe (GDPR) - such as visited websites, data about locally stored files, etc. this behavior does not necessarily inspire trust....Or do you have another opinion?
 

MacDefender

Level 14
Verified
Oct 13, 2019
652
Almost right.
But if the software also passes data unencrypted that is worth protecting in Europe (GDPR) - such as visited websites, data about locally stored files, etc. this behavior does not necessarily inspire trust....Or do you have another opinion?
That kind of data should be SSL encrypted, absolutely. Are you seeing such data be transmitted in clear text too?
If it’s just signatures and database/engine updates, I think that is acceptable to transfer in clear text. If it’s telemetry, cloud scanning requests, etc then no, that should be encrypted.
 

MacDefender

Level 14
Verified
Oct 13, 2019
652
Lead by an example and since Microsoft does it, it is considered OK. Anyway, the overall cost is high, whether is the performance or the price.

Note that the Windows Update attack is kind of scary because they managed to find a compromised certificate that was usable to make Windows think an update was signed.

Sure, in some cases, adding SSL/TLS transport security with certificate pinning makes it harder for an attacker to pull off such an attack, but the root problem there is that Microsoft was not digitally validating the update payload itself correctly, and that they had a compromised certificate authority that should have been revoked. Same kinds of mistakes can happen for poorly managed SSL server instances.

Transferring signed updates over plain HTTP is actually pretty helpful in a lot of enterprise settings because it does allow a simple ordinary caching proxy server to conserve bandwidth for a variety of updates. Otherwise, you end up with a world where for each vendor and for each product, to prevent a 100MB Acrobat Flash or Chrome update from multiplying to 1TB of bandwidth across 10000 computers, you have to set up some special vendor-specific caching server or enterprise update server, and that only works until you realize one day in the future that another software package became more popular and is now slamming your network too.

(In my IT days, it was an utter nightmare especially with smartphones to realize that some release of iOS or Android resulted in the software update scheme changing, and that meant the day that a major vendor pushed out a software update, the whole network would grind to a halt until we figured out how to cache or throttle that particular update mechanism)
 

MacDefender

Level 14
Verified
Oct 13, 2019
652
This is what ESET does,
Excellent, that sounds on paper like the right thing to do to make it safe to transport the signatures over an insecure connection. Well, at least the first part. The second part is classic ESET being ESET: Having something be assembler-based means nothing in terms of preventing a rogue actor from tampering. Having it "compiled locally" sort of means something, but what they are trying to claim is that they have build verifiability, which they are not correctly guaranteeing. Build verifiability involves having trusted builders compile things from verifiable sources, and having a measurement ON the builder (e.g. signed build logs, signed build measurements, or directly having the builder and only the builder be capable of digitally signing, and having an audit trail for if someone attempts to locally log on to the builder during a build)

The build verifiability part is a really hard problem to solve and while I wish in an ideal world a security product vendor gets that right, in practice it's not realistic to expect. I am not going to believe, without a more elaborate design whitepaper, a vendor claim that somehow a rogue sysadmin/employee could not compromise their building/signing process to produce validly signed but maliciously tampered payloads.

FWIW, a lot of times, there's a login credential or license or some other unique identity that AV vendors use for their update server to be willing to hand you new signatures. You can see that sometimes when your trial expires, the AV software says something about the server rejecting login credentials.

Depending on how well that is designed, that could also result in leaking personally identifiable information as a part of grabbing the update.
 

PotentialUser

Level 1
May 28, 2020
35
I bothered and checked the traffic for other programs (Bullguard, Norton and BitDefender).
Conclusion: Disappointing. The majority of the traffic runs over HTTP (nothing is encrypted at Bullguard ..)

Yes, but also for Emsisoft and Gdata :) (At least for me)

I apologize if this is an obvious question but I would like to confirm something.

Are you saying Emsisoft does encrypt their updates or does not encrypt their updates? I’m thinking about purchasing Emsisoft Anti-Malware and this caught my interest.

Many thanks for the testing and your post!
 

MacDefender

Level 14
Verified
Oct 13, 2019
652
I apologize if this is an obvious question but I would like to confirm something.

Are you saying Emsisoft does encrypt their updates or does not encrypt their updates? I’m thinking about purchasing Emsisoft Anti-Malware and this caught my interest.

Many thanks for the testing and your post!
Emsisoft downloads their signatures over plain unencrypted HTTP but we likely believe the signature database itself is signed and verified regardless of the method of transport. It does not allow an arbitrary attacker to inject false signatures and false updates into your machine.
 

Chakuz

Level 1
Jan 22, 2020
12
I apologize if this is an obvious question but I would like to confirm something.

Are you saying Emsisoft does encrypt their updates or does not encrypt their updates? I’m thinking about purchasing Emsisoft Anti-Malware and this caught my interest.

Many thanks for the testing and your post!
GDATA, Emsisoft and WD encrypt almost everything...

Are you seeing such data be transmitted in clear text too?
Yes...of course not all

Basically everyone can reproduce this with Wireshark, pfSense - no great magic ..

F-Secure use http and https - is right. Mor e http than https and Also contact some servers located in the USA (whois owned by Amazon Server, Microsoft - but half the world uses Amazon, is ok)
 
Last edited:

PotentialUser

Level 1
May 28, 2020
35
You may find this interesting @MacDefender. I had an active thread on the Emsisoft forums regarding something else and decided to ask them directly about how their signatures are downloaded. I was fortunate enough to have Mr. Mairoll, founder of Emsisoft, respond to my thread.

This is the reply I received regarding downloading signatures:

Christian Mairoll said:
Our update system was actually one of the first in our industry which implemented advanced manipulation protection, 13-14 years ago, long before SSL became common and at a time when most AVs just had a plain and easy to manipulate file listings to get their updates.

This is how we protect the update trust chain:

1. Update files are encrypted when published, but that's mainly to protect our intellectual property, not to defend hackers.

2. All files are hashed and named by their checksum on our servers.

3. Updates are generally delivered as differential/fragment files that only match with non-manipulated older file versions already on your computer.

4. The update API on our servers provide a list of hashes of all files of the product. The API output is digitally signed, so if it was manipulated, the software would stop the update right away.

5. The software downloads all files that have different hashes than the locally existing files. At that point, any locally made manipulations would be overwritten.

6. Downloads are through HTTPS, e.g.(https://dl.emsisoft.com/updates/CCB6E1DBF0D8220FEF38A77189CC7BB1.dat)

7. After downloading, the software verifies if the hash in the earlier provided download listing matches the actual hash of the files. If there were any manipulations in the download process, e.g. through SSL interception, the files would be rejected at that point.

8. Binary files are also digitally signed, which means if anything gets manipulated on client side, the software won't run anymore and Windows would immediately alert that it's down.

Only if a file can be guaranteed to be and original from Emsisoft, is is being installed. Note that the described security model doesn't even need SSL to be bullet-proof. We just added SSL because it's freely available with our hosting provider.

Link:
I find it important to post his response so MalwareTips users know how seriously Emsisoft takes security — definitely evident from their elaborate update process. They always use SSL and verify all updates through multiple checks before they’re installed on a local machine.

TL;DR: You were correct @Chakuz — everything is encrypted as you originally stated. And, Emsisoft takes things further with even more security enhancements. They are definitely one of a kind and I’m convinced they’re going to provide my main AV solution from now on. Great company through and through.
 
Top