On 2014-04-08 21:57, bmanning wrote:
On Tue, Apr 08, 2014 at 11:46:31PM -0400, Rob Seastrom wrote:
If that's true, you might want to consider immediately disconnecting
your systems from the Internet and never re-connecting them. After
all, theres a lot of online unseen code testing your site al
On 04/09/2014 09:59 AM, Niels Bakker wrote:
Then why single out the .io and .lv's? Maybe you missed the trend (by
now a few years old) to get domains in those and similar ccTLD's for
startups? Why even try to portray them as less trusted, as you
plainly did in the quoted paragraph?
* jsch...@flowtools.net (Me) [Wed 09 Apr 2014, 17:51 CEST]:
On 04/09/2014 09:39 AM, Niels Bakker wrote:
* jsch...@flowtools.net (Me) [Wed 09 Apr 2014, 17:26 CEST]:
Sending someone to a site with obscure TLDs of .io or .lv
doesn't help in these situations. This is a perfect opportunity
for som
On 04/09/2014 09:39 AM, Niels Bakker wrote:
* jsch...@flowtools.net (Me) [Wed 09 Apr 2014, 17:26 CEST]:
Sending someone to a site with obscure TLDs of .io or .lv doesn't
help in these situations. This is a perfect opportunity for someone
to set up a drive by site to drop malware on someone's c
* jsch...@flowtools.net (Me) [Wed 09 Apr 2014, 17:26 CEST]:
Sending someone to a site with obscure TLDs of .io or .lv doesn't
help in these situations. This is a perfect opportunity for someone
to set up a drive by site to drop malware on someone's computer.
Yes, because obviously .com registr
On Apr 09, 2014, at 11:26 , Me wrote:
> On 04/08/2014 09:46 PM, Rob Seastrom wrote:
>> If that's true, you might want to consider immediately disconnecting
>> your systems from the Internet and never re-connecting them. After
>> all, theres a lot of online unseen code testing your site already
>
On 04/08/2014 09:46 PM, Rob Seastrom wrote:
If that's true, you might want to consider immediately disconnecting
your systems from the Internet and never re-connecting them. After
all, theres a lot of online unseen code testing your site already
whether you like it or not.
-r
Sending someone
On Tue, 08 Apr 2014 22:50:26 -0700, Doug Barton said:
> 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 d
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
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
Here's the only way to keep a system safe from Internet hackers:
http://goo.gl/ZvGrXw [google images]
-j
On Tue, Apr 08, 2014 at 11:46:31PM -0400, Rob Seastrom wrote:
>
> Me 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
Me 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 re-connecting them. Af
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:
> > https://github.com/musalbas/heartb
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: http://filippo.
014 1:19 AM
> To: nanog@nanog.org
> Subject: Re: Serious bug in ubiquitous OpenSSL library: "Heartbleed"
>
> Not just run the updates -- all private keys should be changed too, on
> the assumption that they've been compromised already. THAT is going to
> be the crappy part
Once upon a time, Frank Bulk 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 the load-balance
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 clien
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
---
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 wro
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 what
rom: 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: "Heartbleed"
Not just run the updates -- all private keys should be changed too, on
the assumption that they've been comp
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 li
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 ot
Not just run the updates -- all private keys should be changed too, on
the assumption that they've been compromised already. THAT is going to
be the crappy part of this.
- Pete
On 4/8/2014 1:13 AM, David Hubbard wrote:
RHEL and CentOS both have patches out as of a couple hours
ago, so run t
RHEL and CentOS both have patches out as of a couple hours
ago, so run those updates! CentOS' mirrors do not all have
it yet, so if you are updating, make sure you get the
1.0.1e-16.el6_5.7 version and not older.
David
-Original Message-
From: Paul Ferguson [mailto:fergdawgs...@mykolab.c
26 matches
Mail list logo
