Forums
New posts
Search forums
News
Security News
Technology News
Giveaways
Giveaways, Promotions and Contests
Discounts & Deals
Reviews
Users Reviews
Video Reviews
Support
Windows Malware Removal Help & Support
Mac Malware Removal Help & Support
Mobile Malware Removal Help & Support
Blog
Log in
Register
What's new
Search
Search titles only
By:
Search titles only
By:
Reply to thread
Menu
Install the app
Install
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Forums
Security
General Security Discussions
Why security suites use an insecure connection?
Message
<blockquote data-quote="MacDefender" data-source="post: 885414" data-attributes="member: 83059"><p>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)</p><p></p><p>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.</p><p></p><p>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.</p><p></p><p>Depending on how well that is designed, that could also result in leaking personally identifiable information as a part of grabbing the update.</p></blockquote><p></p>
[QUOTE="MacDefender, post: 885414, member: 83059"] 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. [/QUOTE]
Insert quotes…
Verification
Post reply
Top