Slashdot Mirror

Hash the password AND block number through a key-stretching routine to get the encryption key. It is important to avoid using the same key for all blocks. If different blocks are XORed with the same key, I can still see your penguin:
https://blog.filippo.io/the-ec...

https://blog.filippo.io/so-i-l...

TL;DR: jump to Chapter IV

For OS X: https://blog.filippo.io/untrusting-an-intermediate-ca-on-os-x/

For WIndows: http://blogs.msmvps.com/alunj/2016/05/26/untrusting-the-blue-coat-intermediate-ca-from-windows/

And why you should: https://motherboard.vice.com/read/a-controversial-surveillance-firm-was-granted-a-powerful-encryption-certifica

Not quite. The core beef seems to be that the commonly used STARTTLS method of SMTP transport encryption is essentially optional, which allows hackers to use a variety of methods to force-downgrade target connections (in situations where mature implementations of HTTPS would have safely blown up). In other words, the authors are seeking a world where you install your mail server cert just like you install your web server cert, and it all works fairly securely out of the box. The reality is that it's early yet, but a lot of the work seems to be needed on the part of application developers rather than IT right now.

See https://blog.filippo.io/the-sa...

I thought that Gmail actually circumvented this with an image caching service, but when I (just) researched it, it doesn't (it only does proxying):
"Also, no caching is performed server-side, every time I downloaded that URL, a request showed up on my server." ( https://filippo.io/how-the-new... )

"In some cases, senders may be able to know whether an individual has opened a message with unique image links. As always, Gmail scans every message for suspicious content and if Gmail considers a sender or message potentially suspicious, images won’t be displayed and you’ll be asked whether you want to see the images." ( https://support.google.com/mai... )

It would be better to just preload all (or at least a random subset) of the images for emails sent to the Gmail servers, thereby poisoning the information stream of spammers to the point of being useless. On the other hand, that means disregarding any caching directives and is perhaps too expensive, resource-wise.

Did _you_ know that your wireless router was using OpenSSL to manage EAP? Or did you just assume that having SSH blocked and not serving HTTPS would be enough?

And even if you did, is it even possible for you to upgrade a single library on your access point?

Try going back to the original CVE, the plethora of vulnerability checkers, or any of the press surrounding it. Every reference to Heartbleed pointed to HTTPS or, rarely, TLS and VPN services as being vulnerable to the bug. Now pretend that you don't know the implementation details of WPA and EAP. Based on all of that, why would you even consider updating or replacing every wireless device you have which don't use HTTPS unless the manufacturer told you?

Moreover, when have manufacturers of popular wireless equipment _ever_ produced timely and relevant updates without at least eight months lead time and court cases in at least three countries?

Thank you. This is good to know. I used, https://filippo.io/Heartbleed/, to test my web facing services. No affiliation. I found it through Google.

Testing does back up the bank's claims. RBC, CIBC, TD, Scotia, BMO, CWB, PCF, Tangerine, all of them show as unaffected on Filippo's tester.

I used the http://filippo.io/Heartbleed page before and after patching my server, and it appears to work ok (reported "vulnerable" before, and "fixed" after).

The only client side tool I've encountered is at http://filippo.io/Heartbleed/ Can't speak to the implementation or even if it actually checks. But it purports to check in real time and if you trust it you can check sites prior to changing passwords.

http://filippo.io/Heartbleed/

Filippo Valsorda's online tool for checking web servers for the Heartbleed vulnerability is quite an eye opener. As well as telling you whether the server is vulnerable, it displays a small snippet of the memory it retrieved (there are scripts on Github that will show you the whole 64KB I believe).

In the quick tests I did on login.yahoo.com (used for Yahoo's email and probably all other Yahoo services), I saw three different user's passwords and at least part of their usernames. And you can just sit there refreshing the page to see more! Madness!