

Amazon ELBs are vulnerable to Heartbleed - lox
https://forums.aws.amazon.com/thread.jspa?threadID=149734&tstart=0

======
pjjw
amazon's response on this has been absolutely disgusting. we pay for their
enterprise support, and that team is completely unaware. last night they
advised that if i wanted this fixed in a day i should consider terminating my
own ssl. i set that up, and as soon as i was about to cut over, i noticed that
our elbs were fixed.

as of now, support is unaware there is a fix being rolled out.

i would have been better served not speaking to them, let alone paying for aws
support.

~~~
flyt
We've had the exact opposite experience: After reaching out to Amazon our ELBs
were prioritized for the fix and patched with no work needed on our part
within <8 hours. Our rep has been in constant contact the whole time.

~~~
pjjw
did you contact your account rep or go through support? if the former, that
makes sense. ours is traveling..

~~~
flyt
We filed a ticket through support and also contacted our rep, referencing the
ticket.

------
lox
It looks like they are actually fixed, as of 1 hour ago:

[https://twitter.com/lox/status/453443517017100288](https://twitter.com/lox/status/453443517017100288)
[http://filippo.io/Heartbleed/#99designs.com](http://filippo.io/Heartbleed/#99designs.com)

~~~
bradly
Our servers in us-west-1 are still showing as vulnerable sometimes. Even with
that 99 designs link, if I refresh sometimes if passes and sometimes it fails.
Possibly the patch is still being rolled out?

~~~
eknkc
I think they started rolling it out into eu-west too. Our hosts return
"vulnerable" 50% of the time now.

------
lox
Seems like CloudFront is still vulnerable:
[http://filippo.io/Heartbleed/#d8u1nmttd4enu.cloudfront.net:4...](http://filippo.io/Heartbleed/#d8u1nmttd4enu.cloudfront.net:443)

~~~
duongkai
According cloudflare blog: Today a new vulnerability was announced in OpenSSL
1.0.1 that allows an attacker to reveal up to 64kB of memory to a connected
client or server (CVE-2014-0160). _We fixed this vulnerability last week
before it was made public_. All sites that use CloudFlare for SSL have
received this fix and are automatically protected.

[1][http://blog.cloudflare.com/staying-ahead-of-openssl-
vulnerab...](http://blog.cloudflare.com/staying-ahead-of-openssl-
vulnerabilities)

~~~
drdaeman
In a same manner CloudFlare had it before the disclosure, OpenSSL team
should've contacted major GNU distro (Debian, Fedora, Arch) packagers
privately and do the announcement as new releases hit the repos (i.e. not
having a 4-8 hour window, given the bug's pretty much critical).

~~~
001spartan
I was under the impression that they did in fact contact package maintainers
in addition to companies like CloudFlare.

~~~
rincebrain
Nope; package maintainers said they didn't get notified, and OpenSSL
explicitly has no notification mechanism for such things. CF found out because
the private entities which found the bug warned them a priori with a request
to not disclose it to anyone else. See also:
[https://news.ycombinator.com/item?id=7549986](https://news.ycombinator.com/item?id=7549986)

------
jeffbarr
Here is the official update: [http://aws.amazon.com/security/security-
bulletins/aws-servic...](http://aws.amazon.com/security/security-
bulletins/aws-services-updated-to-address-openssl-vulnerability/)

------
lox
Werner posted this:

[https://aws.amazon.com/security/security-
bulletins/heartblee...](https://aws.amazon.com/security/security-
bulletins/heartbleed-bug-concern/)

Wonder where this is even linked from?

~~~
mmelin
Apparently there is a Security Bulletins page, but I wasn't aware of it until
you posted this link. [https://aws.amazon.com/security/security-
bulletins/](https://aws.amazon.com/security/security-bulletins/)

Just used Zapier to set up a RSS-to-email trigger to get notified about things
like this in the future, although Amazon really should be sending them out
automatically to customers.

~~~
lox
Great idea, I just setup an RSS-to-slack trigger for future notifications:
[http://zpr.io/HSkn](http://zpr.io/HSkn)

~~~
tlogan
Great!

./heartbleeder zapier.com

VULNERABLE - zapier.com:443 has the heartbeat extension enabled and is
vulnerable to CVE-2014-0160

~~~
bryanh
AWS's ELB (which we use) were vulnerable, we'll be replacing certificates
ASAP. We (and most the rest of the internet using ELB) seem to be in the clear
now:

    
    
        ./heartbleeder zapier.com
        SECURE - zapier.com:443 has the heartbeat extension enabled, but timed out after a malformed heartbeat (this likely means that it is not vulnerable)
    

When did you run your check? Do you have a recent binary of heartbleeder?

------
_mikz
How CloudFlare got patched last week and AWS not?

~~~
tszming
I am also interested to know why CloudFlare is ahead of those major Linux
distributions on this.

~~~
hrrsn
Simple. Someone alerted them ahead of time since they terminate a lot of SSL
connections. Testing with distros is a lot harder.

~~~
tszming
CloudFlare will not terminate SSL for free users - only for the paid plans. I
will be also surprised if they really terminate more SSL connections than AWS
ELB & CloudFront. I am not saying CloudFlare did anything wrong - they are
doing great this time. I am wondering if other parties like AWS received the
disclosure at the same time, what they are waiting? CloudFlare fixed the issue
last week, not yesterday.

------
jensnockert
Heroku is also still vulnerable, which makes me slightly uncomfortable.

~~~
whatts
Me too. And I feel they won't be the fastest here ... Certainly a downside of
Heroku, where you cannot just re-compile and fix things yourself.

~~~
cardmagic
There are new tools[1] being built around Docker that make it viable to easily
move your apps out of Heroku and onto any system running Docker including
DigitalOcean, GCE, AWS, etc.

When you combine Docker, buildpacks, and CoreOS[2], you get a scalable and
flexible platform that you can run anywhere. It has taken people a long time
to combine the simplicity of Heroku with the flexibility of bare metal, but
the open source guys have finally put all the building blocks together.

[1]
[https://github.com/CenturyLinkLabs/building/](https://github.com/CenturyLinkLabs/building/)

[2] [http://www.centurylinklabs.com/building-your-first-app-on-
co...](http://www.centurylinklabs.com/building-your-first-app-on-coreos/)

~~~
bacongobbler
Another tool that does just this would be Deis[1]. We specifically combine
CoreOS (in heavy development[2]), Docker, Heroku Buildpacks, and also
Dockerfile deployments[3], too!

[1]: [http://deis.io/](http://deis.io/)

[2]:
[https://github.com/opdemand/deis/issues/530](https://github.com/opdemand/deis/issues/530)

[3]:
[http://docs.deis.io/en/latest/developer/dockerfile/#deploy-u...](http://docs.deis.io/en/latest/developer/dockerfile/#deploy-
using-dockerfiles)

------
madaxe_again
We have over 200 ELBs, and therefore over 200 SSL certificates to go and
manually replace. Time for gin.

~~~
ukd1
time to automate -
[http://docs.aws.amazon.com/ElasticLoadBalancing/latest/APIRe...](http://docs.aws.amazon.com/ElasticLoadBalancing/latest/APIReference/Welcome.html)
:-)

~~~
madaxe_again
Oh, we automate that end of things, our cloud is all chef managed... but
getting 200 certs re-issued by a dozen different issuers with new private keys
is, how you say, tedious.

~~~
toomuchtodo
Yep. Still time for $drinkOfChoice. I threw my whole todo list for today out
the window this morning.

------
wwarren
I have 3 ELBs. 1 seems fixed, and the other 2 still vulnerable...get your shit
together Amazon!

~~~
jmathai
I manually created a new ELB which seemed to have been fixed and then updated
DNS.

