It's bad. I decided to test my servers after updating them. Took me
about 3 hours to write a working implementation of this attack without
any prior knowledge of TLS internals. It's easy to do, pretty much
impossible to detect, and it's going to spread quickly. Shut down your
https sites and any
I'm really surprised no one has mentioned this here yet...
we're all to damned busy updating and generating keys
you might like (thanks smb, or was it sra)
openssl s_client -connect google\.com:443 -tlsextdebug 21| grep 'server
extension heartbeat (id=15)' || echo safe
randy, who is almost
Hi Mark,
On Thu, 3 Apr 2014, Mark Tinka wrote:
On Thursday, April 03, 2014 02:22:44 AM Randy Bush wrote:
and, btw, how many of those whose prefixes were
mis-originated had registered those prefixes in the
rpki?
It is probably a bit of a hammer at this stage, but we are
in limited
Hi, Joe,
On 04/02/2014 03:14 PM, Joe Abley wrote:
Is anybody aware of any wide-scale studies that examine the
probability of fragmentation of datagrams of different sizes?
We're in the process of measuring some (kind of related stuff). If
you're interested in this data, we might be able to
On Tuesday, April 08, 2014 11:24:07 AM Jac Kloots wrote:
We (SURFnet, AS1103) are in the same position and I wrote
an article about the evaluation we did before deciding
on dropping invalids (https://blog.surfnet.nl/?p=3159)
Sounds great, Jac!
In your report, you mention that you're not
Mark,
On Tue, 8 Apr 2014, Mark Tinka wrote:
On Tuesday, April 08, 2014 11:24:07 AM Jac Kloots wrote:
We (SURFnet, AS1103) are in the same position and I wrote
an article about the evaluation we did before deciding
on dropping invalids (https://blog.surfnet.nl/?p=3159)
Sounds great, Jac!
On Tue, Apr 8, 2014 at 4:35 AM, Randy Bush ra...@psg.com wrote:
I'm really surprised no one has mentioned this here yet...
we're all to damned busy updating and generating keys
you might like (thanks smb, or was it sra)
openssl s_client -connect google\.com:443 -tlsextdebug 21| grep
Don't forget to restart every daemon that was using the old library as
well, or just reboot.
-Original Message-
From: Peter Kristolaitis [mailto:alte...@alter3d.ca]
Sent: Tuesday, April 08, 2014 1:19 AM
To: nanog@nanog.org
Subject: Re: Serious bug in ubiquitous OpenSSL library:
If you built anything against the vulnerable library (esp static linked
stuff), you'll need to rebuild those too.
On 4/8/2014 午後 09:18, David Hubbard wrote:
Don't forget to restart every daemon that was using the old library as
well, or just reboot.
-Original Message-
From: Peter
Randy Bush ra...@psg.com writes:
you might like (thanks smb, or was it sra)
openssl s_client -connect google\.com:443 -tlsextdebug 21| grep 'server
extension heartbeat (id=15)' || echo safe
protip: you have to run this from a device that actually is running
1.0.x, i.e. supports the
On Tuesday, April 08, 2014 01:20:23 PM Jac Kloots wrote:
Yes, we don't validate those prefixes cause we filter
them strict. We know from all our customers which
prefixes they use so we have prefix-filters placed on
all their connections.
Good point.
We do both - prefix list + AS_PATH
Just as a data point, I checked the servers I run and it's a good thing
I didn't reflexively update them first.
On Centos 6.0, the default openssl is 1.0.0 which supposedly doesn't
have the vulnerability, but the
ones queued up for update do. I assume that redhat will get the patched
version
The updated CentOS openssl binaries haven't patched the underlying bug, but
they have disabled the heartbeat functionality. By doing so, they've
disabled the attack vector. Once upstream releases a fix, they will
re-enable the heartbeat function with the working patch.
And yes, don't forget to
For testing, I've had good luck with
https://github.com/titanous/heartbleeder and
https://gist.github.com/takeshixx/10107280
Both are mostly platform-independent, so they should be able to work even
if you don't have a modern OpenSSL to test with.
Cheers and good luck (you're going to need it),
1.0.1 was not deployed until RHEL 6.5. RedHat released patches
for RHEL last night, and CentOS followed suit a few minutes
later.
-Original Message-
From: Michael Thomas [mailto:m...@mtcc.com]
Sent: Tuesday, April 08, 2014 12:03 PM
To: nanog@nanog.org
Subject: Re: Fwd: Serious bug in
Lots of tools available. I'm with ferg, surprised more haven't been mentioned
here.
Tools to check for the bug:
• on your own box:
https://github.com/musalbas/heartbleed-masstest/blob/master/ssltest.py
• online: http://filippo.io/Heartbleed/ (use carefully as they might
log
According to the changelog it cvs is fixed now.
$ rpm -qa|grep openssl
openssl-1.0.1e-16.el6_5.7.x86_64
openssl-devel-1.0.1e-16.el6_5.7.x86_64
Tue Apr 8 12:17:25 EDT 2014
Z643357:~
$ rpm -q --changelog openssl | less
* Mon Apr 07 2014 Tomás( Mráz tm...@redhat.com 1.0.1e-16.7
- fix CVE-2014-0160
Hi,
someone knowing a security contact for web.de, please contact me off list.
Thanks!
Regards,
Ruben
Here's mine, written in Go:
http://code.google.com/p/mxk/source/browse/go1/tlshb/
To build the binary, install Mercurial, install Go (golang.org), set
GOPATH to some empty directory, then run:
go get code.google.com/p/mxk/go1/tlshb
- Max
On Tue, Apr 8, 2014 at 12:16 PM, Patrick W. Gilmore
The NANOG on the Road series will be coming to Los
Angeleshttps://www.nanog.org/meetings/road3/homeon May 20, 2014.
Hosted by NANOG in partnership with Los Nettos at the USC
campus, the program will include research and education presentations along
with relevant NANOG meeting content. Topics to
If we would front our HTTPS services with a (OpenSSL vulnerable)
load-balancer that does the SSL work and we just use HTTP to the service,
will that mitigate information loss that's possible with this exploit? Or
will the OpenSSL code on the load-balancer also store or cache content?
Frank
You can still potentially access all the same information since it all goes
through the load balancer. Interesting bits of info are things like Cookie:
headers being sent by clients and sitting in a buffer. Try one of the testing
tools mentioned and see if you can see any info from other
Once upon a time, Frank Bulk frnk...@iname.com said:
If we would front our HTTPS services with a (OpenSSL vulnerable)
load-balancer that does the SSL work and we just use HTTP to the service,
will that mitigate information loss that's possible with this exploit? Or
will the OpenSSL code on
Hi,
I was wondering why most of my secure services didn't show up as
vulnerable...
-
It do not seems to affect those services that require a valid user
certificate.
aka, in apache 2.2
SSLVerifyClient Require
SSLVerifyDepth 1 (up to 10)
I couldn't find
Please contact me off list?
Thank you.
On 04/08/2014 10:16 AM, Patrick W. Gilmore wrote:
Lots of tools available. I'm with ferg, surprised more haven't been mentioned
here.
Tools to check for the bug:
• on your own box:
https://github.com/musalbas/heartbleed-masstest/blob/master/ssltest.py
• online:
On Tue, Apr 08, 2014 at 05:56:45PM -0600, Me wrote:
On 04/08/2014 10:16 AM, Patrick W. Gilmore wrote:
Lots of tools available. I'm with ferg, surprised more haven't been
mentioned here.
Tools to check for the bug:
• on your own box:
Me jsch...@flowtools.net writes:
Thanks for the expanded list, I had some of these already. I'm not
comfortable in letting some online code that I can't see test my site
though.
If that's true, you might want to consider immediately disconnecting
your systems from the Internet and never
On Tue, Apr 08, 2014 at 11:46:31PM -0400, Rob Seastrom wrote:
Me jsch...@flowtools.net writes:
Thanks for the expanded list, I had some of these already. I'm not
comfortable in letting some online code that I can't see test my site
though.
If that's true, you might want to consider
Here's the only way to keep a system safe from Internet hackers:
http://goo.gl/ZvGrXw [google images]
-j
On Wed, Apr 09, 2014 at 12:18:00AM -0500, jamie rishaw wrote:
Here's the only way to keep a system safe from Internet hackers:
http://goo.gl/ZvGrXw [google images]
/me is disappointed that wasn't a pair of scissors
- Matt
--
Sure, it's possible to write C in an object-oriented way. But,
On 04/08/2014 10:28 PM, Matt Palmer wrote:
On Wed, Apr 09, 2014 at 12:18:00AM -0500, jamie rishaw wrote:
Here's the only way to keep a system safe from Internet hackers:
http://goo.gl/ZvGrXw [google images]
/me is disappointed that wasn't a pair of scissors
... or a backhoe
32 matches
Mail list logo
