Re: Serious bug in ubiquitous OpenSSL library: Heartbleed

2014-04-08 Thread Maxim Khitrov
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 other TLS services until you've updated OpenSSL,
then think about changing your private keys.

- Max

On Tue, Apr 8, 2014 at 1:06 AM, Paul Ferguson fergdawgs...@mykolab.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 I'm really surprised no one has mentioned this here yet...

 FYI,

 - - ferg



 Begin forwarded message:

 From: Rich Kulawiec r...@gsp.org Subject: Serious bug in
 ubiquitous OpenSSL library: Heartbleed Date: April 7, 2014 at
 9:27:40 PM EDT

 This reaches across many versions of Linux and BSD and, I'd
 presume, into some versions of operating systems based on them.
 OpenSSL is used in web servers, mail servers, VPNs, and many other
 places.

 Writeup: Heartbleed: Serious OpenSSL zero day vulnerability
 revealed
 http://www.zdnet.com/heartbleed-serious-openssl-zero-day-vulnerability-revealed-728166/

  Technical details: Heartbleed Bug http://heartbleed.com/

 OpenSSL versions affected (from link just above):  OpenSSL 1.0.1
 through 1.0.1f (inclusive) are vulnerable OpenSSL 1.0.1g is NOT
 vulnerable (released today, April 7, 2014) OpenSSL 1.0.0 branch is
 NOT vulnerable OpenSSL 0.9.8 branch is NOT vulnerable



 - --
 Paul Ferguson
 VP Threat Intelligence, IID
 PGP Public Key ID: 0x54DC85B2
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.22 (MingW32)
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iF4EAREIAAYFAlNDg9gACgkQKJasdVTchbIrAAD9HzKaElH1Tk0oIomAOoSOvfJf
 3Dvt4QB54os4/yewQQ8A/0dhFZ/YuEdA81dkNfR9KIf1ZF72CyslSPxPvkDcTz5e
 =aAzE
 -END PGP SIGNATURE-




Re: Fwd: Serious bug in ubiquitous OpenSSL library: Heartbleed

2014-04-08 Thread Maxim Khitrov
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 'server 
 extension heartbeat (id=15)' || echo safe

That just tells you whether the heartbeat extension is supported.
Google servers are not vulnerable to this attack.

- Max



Re: Serious bug in ubiquitous OpenSSL library: Heartbleed

2014-04-08 Thread Maxim Khitrov
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 patr...@ianai.net 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.io/Heartbleed/ (use carefully as they might 
 log what you check)
 • online: http://possible.lv/tools/hb/
 • offline: https://github.com/tdussa/heartbleed-masstest --- Tobias 
 Dussa, also Takes a CSV file with host names for input and ports as parameter
 • offline: http://s3.jspenguin.org/ssltest.py
 • offline: https://github.com/titanous/heartbleeder

 List of vulnerable Linux distributions: http://www.circl.lu/pub/tr-21/.

 Anyone have any more?

 --
 TTFN,
 patrick


 On Apr 08, 2014, at 12:11 , Jonathan Lassoff j...@thejof.com wrote:

 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),
 jof

 On Tue, Apr 8, 2014 at 5:03 PM, Michael Thomas m...@mtcc.com wrote:

 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 soon but be careful!

 Mike


 On 04/07/2014 10:06 PM, Paul Ferguson wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 I'm really surprised no one has mentioned this here yet...

 FYI,

 - - ferg



 Begin forwarded message:

 From: Rich Kulawiec r...@gsp.org Subject: Serious bug in
 ubiquitous OpenSSL library: Heartbleed Date: April 7, 2014 at
 9:27:40 PM EDT

 This reaches across many versions of Linux and BSD and, I'd
 presume, into some versions of operating systems based on them.
 OpenSSL is used in web servers, mail servers, VPNs, and many other
 places.

 Writeup: Heartbleed: Serious OpenSSL zero day vulnerability
 revealed
 http://www.zdnet.com/heartbleed-serious-openssl-zero-day-vulnerability-
 revealed-728166/

  Technical details: Heartbleed Bug http://heartbleed.com/

 OpenSSL versions affected (from link just above):  OpenSSL 1.0.1
 through 1.0.1f (inclusive) are vulnerable OpenSSL 1.0.1g is NOT
 vulnerable (released today, April 7, 2014) OpenSSL 1.0.0 branch is
 NOT vulnerable OpenSSL 0.9.8 branch is NOT vulnerable


 - -- Paul Ferguson
 VP Threat Intelligence, IID
 PGP Public Key ID: 0x54DC85B2
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.22 (MingW32)
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iF4EAREIAAYFAlNDg9gACgkQKJasdVTchbIrAAD9HzKaElH1Tk0oIomAOoSOvfJf
 3Dvt4QB54os4/yewQQ8A/0dhFZ/YuEdA81dkNfR9KIf1ZF72CyslSPxPvkDcTz5e
 =aAzE
 -END PGP SIGNATURE-








Re: Gmail and SSL

2013-01-03 Thread Maxim Khitrov
On Thu, Jan 3, 2013 at 12:14 AM, Damian Menscher dam...@google.com wrote:
 Back on topic: encryption without knowing who you're talking to is worse
 than useless (hence no self-signed certs which provide a false sense of
 security), and there are usability difficulties with exposing strong
 security to the average user (asking users to generate and upload a
 self-signed cert would be a customer-support disaster, not to mention all
 the outages that would occur when those certs expired).  Real-world
 security is all about finding a reasonable balance and adapting to the
 current threats.

The most recent change to POP3 mail retrieval over SSL is not a
reasonable balance. My organization uses Google Apps for mail hosting,
but a number of users also have us.army.mil accounts. They used to
pull mail from their .mil account into Google Apps via POP3. Army
servers do not allow unencrypted connections and their root
certificates are not part of the Mozilla Root CA list (and, as you can
guess, I have no control over their servers).

Google didn't just block the use of self-signed certs; you broke
communication with all servers using perfectly legitimate PKIs that
are not part of the Mozilla Root CA list. Thus, instead of
self-signed certs = false sense of security, your argument is really
not on some arbitrary root CA list = false sense of security, which
is absolute nonsense.

I talked to Google Apps support a few weeks ago, sent them a link to
this discussion, but all they could do is file a feature request.
IMHO, this change should never have been allowed to go into production
until there is an interface for uploading our own root certificates.
Of course, any root (i.e. self-signed) certificate can be used by the
POP3 server directly, so this would also solve the problem for people
trying to use self-signed certs not part of any PKI.

Finally, asking users to generate and upload a self-signed cert would
be a customer-support disaster, so you just block their access
completely? Anyone who doesn't know how to generate and upload a
certificate would probably avoid encryption altogether, don't you
think? And as for outages that would occur when those certs expired,
what do you think people in my organization are dealing with right
now? Only an expired cert can be renewed or replaced, whereas our
access has been blocked and there is nothing we can do about it.

- Max



Re: Gmail and SSL

2012-12-14 Thread Maxim Khitrov
On Fri, Dec 14, 2012 at 10:52 AM, Peter Kristolaitis alte...@alter3d.ca wrote:
 On 12/14/2012 10:47 AM, Randy wrote:

 I don't have hundreds of dollars to get my ssl certificates signed


 You can get single-host certificates issued for free from StartSSL, or for
 very cheaply (under $10) from low-cost providers like CheapSSL.com.  I've
 never had a problem having my StartSSL certs verified by anyone.

This doesn't solve the problem if you have your own internal PKI or
want to use a certificate that is valid for more than a year. StartSSL
is a good option, but not everyone will be able to switch for a
variety of reasons. Google should provide a way of uploading trusted
root CAs (including self-signed certs) if they want to perform strict
validation.

- Max



Re: Looking for recommendation on 10G Ethernet switch

2012-11-02 Thread Maxim Khitrov
On Fri, Nov 2, 2012 at 4:10 PM, Jeff Wheeler j...@inconcepts.biz wrote:
 On Fri, Nov 2, 2012 at 11:13 AM, Eric Germann egerm...@limanews.com wrote:
 I'm looking for a recommendation on a smallish 10G Ethernet switch for a
 small virtualization/SAN implementation (4-5 hosts, 2 SAN boxes) over
 iSCSI with some legacy boxes on GigE.

 1Gbps.   Assessing whether it is better to go 10G now vs. multi-pathing
 with quad GigE cards.  Trying to find the best solution for  1G on a
 trunk and  $50K per box.

 Certainly the days of doing NxGE to servers should be behind us.
 There are many good 10GE switch offerings.  The Juniper QFX and Arista
 (insert one of three good product lines here) have been excellent for
 us.  We like them for different reasons -- Arista is quite good if you
 want to integrate with a provisioning system; QFX is our choice when
 most provisioning is done manually.  Both are way under $50k per box.

 The biggest difference between the TOR-style switches and chassis
 offerings, aside from the obvious, is buffers.  All the TOR-type 10G
 switches have really small buffers and that can be a performance issue
 for iSCSI when utilization is high.  Most of the chassis-type switches
 have very generous buffers so you do not run into problems with
 micro-bursting, etc.  The vendors will all tell you about lossless
 ethernet, flow control, etc. and that crap sounds great on paper.  Try
 making it actually work.  You'll want those days of your life back. :)

I'm curious if anyone here has experience with the Extreme Summit X650
or X670 switches? I'm also currently looking for 10GBASE-T switch for
my first SAN, but one with 48 ports. The price for X670V-48T seems
reasonable, but I have no experience with 10 GbE over copper, so it's
difficult to figure out what criteria to use (other than price) when
comparing Extreme, Arista, Dell, and others. Any tips?

- Max