Forum: NGINX OpenSSL leaks server-Keys / The Heartbleed Bug

2974d09ac2541e892966b762aad84943?d=identicon&s=25 mex (Guest)
on 2014-04-08 12:51
(Received via mailing list)
A missing bounds check in the handling of the TLS heartbeat extension
can be used to reveal up to 64k of memory to a connected client or
server.


https://www.openssl.org/news/secadv_20140407.txt
http://heartbleed.com/
http://www.reddit.com/r/netsec/comments/22gym6/dia...
http://security.stackexchange.com/search?q=heartbleed


regards,


mex

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,249102,249102#msg-249102
2974d09ac2541e892966b762aad84943?d=identicon&s=25 mex (Guest)
on 2014-04-09 00:19
(Received via mailing list)
Guide to Nginx + SSL + SPDY has been updated with some infos, links and
tests
regarding heartbleed

https://www.mare-system.de/guide-to-nginx-ssl-spdy...




regards,

mex

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,249102,249131#msg-249131
D207dfc04524519f516e3f32df986d2e?d=identicon&s=25 Raul Hugo (Guest)
on 2014-04-09 00:22
(Received via mailing list)
I see this on Linux-Plug list:

"If your operating system uses OpenSSL 1.0.1 its servers are vulnerable.

CentOS and pulled his patch here:

http://lists.centos.org/pipermail/centos-announce/...

If you have servers with Ubuntu 12.04 LTS you should take a look at this
discussion:

http://serverfault.com/questions/587574/apache-2-i...


2014-04-08 17:18 GMT-05:00 mex <nginx-forum@nginx.us>:

>
> mex
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?2,249102,249131#msg-249131
>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>



--
Un abrazo!


*Ral Hugo <http://twitter.com/raulhugo>*


*Miembro Asociadohttp://apesol.org.pe <http://apesol.org.pe/>SysAdmin
Cel.
#961-710-096  Linux Registered User #482081 - http://counter.li.org/
<http://counter.li.org/>P Antes de imprimir este e-mail piense bien si
es
necesario hacerlo*
1266aa99d1601b47bbd3ec22affbb81c?d=identicon&s=25 B.R. (Guest)
on 2014-04-09 01:02
(Received via mailing list)
There is not much to learn from a gujide that what has alrfeady been
said
on http://heartbleed.com.

More specifically, there is nothing related to nginx nor SPDY...
Heartbleed is related to OpenSSL and the solution is either to update
your
OpenSSL version/package with the official/your distro repository one and
restart OpenSSL-related processes to load the fixed library or recompile
your current library removing the support of the heartbeat capability.
On a side note, people having no use of heartbeat and having a fixed
version orf OpenSSL are advised to disable this capability to make the
trackdown of vulnerable versions easier in the near future in the
eventuality of a coordinated action to detect them and alert
administrators
responsible for the affected systems.

*I suspect your are attempting to bring traffic to your website at all
costs with a pointless and misleading article... I despise that.*
---
*B. R.*
419b29425e1245886d653616ba381f00?d=identicon&s=25 Maxim Konovalov (Guest)
on 2014-04-09 11:23
(Received via mailing list)
On 4/9/14 2:18 AM, mex wrote:
> Guide to Nginx + SSL + SPDY has been updated with some infos, links and
> tests
> regarding heartbleed
>
> https://www.mare-system.de/guide-to-nginx-ssl-spdy...
>
Also it's worth to look at the recent nginx blog post regarding
heartbleed:

http://nginx.com/blog/nginx-and-the-heartbleed-vul...

--
Maxim Konovalov
http://nginx.com
2974d09ac2541e892966b762aad84943?d=identicon&s=25 mex (Guest)
on 2014-04-09 20:47
(Received via mailing list)
> Also it's worth to look at the recent nginx blog post regarding
> heartbleed:
>
> http://nginx.com/blog/nginx-and-the-heartbleed-vul...
>


thanx for the link maxim, has been incorporated




regards,

mex

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,249102,249178#msg-249178
40b4c848b8fcd63b0cb60b9d170c3a77?d=identicon&s=25 Valentin V. Bartenev (Guest)
on 2014-04-11 18:12
(Received via mailing list)
"Answering the Critical Question: Can You Get Private SSL Keys Using
Heartbleed?"
@
http://blog.cloudflare.com/answering-the-critical-...

  wbr, Valentin V. Bartenev
7e5b9e3ef674f859551ae0e283061b52?d=identicon&s=25 Jim Ohlstein (Guest)
on 2014-04-11 18:35
(Received via mailing list)
Hello,

On 4/11/14, 12:11 PM, Valentin V. Bartenev wrote:
> "Answering the Critical Question: Can You Get Private SSL Keys Using
Heartbleed?"
> @
http://blog.cloudflare.com/answering-the-critical-...
>

Thanks for the link. On a quick read it seems their conclusion is that
while it is *extremely* unlikely that your private key(s) was/were
stolen using nginx, you should still re-key and revoke. While
comforting, not really of any great practical help.

Nice that CloudFlare (and no doubt others) received significant advance
warning while the rest of us were left vulnerable. Just sayin...

--
Jim Ohlstein


"Never argue with a fool, onlookers may not be able to tell the
difference." - Mark Twain
499e9a842ab8b295c80d71e4276d7ad0?d=identicon&s=25 Philipp (Guest)
on 2014-04-11 18:41
(Received via mailing list)
Am 11.04.2014 18:34 schrieb Jim Ohlstein:
> Thanks for the link. On a quick read it seems their conclusion is
> that while it is *extremely* unlikely that your private key(s)
> was/were stolen using nginx, you should still re-key and revoke. While
> comforting, not really of any great practical help.

Adding info from
http://arstechnica.com/security/2014/04/heartbleed...
it looks like for tests so far only freebsd/apache2 is a combo where
private key data could leak.

> Nice that CloudFlare (and no doubt others) received significant
> advance warning while the rest of us were left vulnerable. Just
> sayin...

Really.. those with deep pockets get warning "in advance". Blah.
63f341734581b167c7b698169bdd2510?d=identicon&s=25 Lukas Tribus (Guest)
on 2014-04-12 13:15
(Received via mailing list)
Hi,


> Thanks for the link. On a quick read it seems their conclusion is that
> while it is *extremely* unlikely that your private key(s) was/were
> stolen using nginx, you should still re-key and revoke. While
> comforting, not really of any great practical help.

They updated the post, their initial analysis was wrong.

Also see:
http://blog.cloudflare.com/the-results-of-the-clou...



> Nice that CloudFlare (and no doubt others) received significant advance
> warning while the rest of us were left vulnerable. Just sayin...

They had no choice. They couldn't notify a lot of people about this, it
would have been leaked to exploit kits and black hats before OpenSSL
provided the bugfix. That would have been a lot worse.



Regards,

Lukas
2974d09ac2541e892966b762aad84943?d=identicon&s=25 itpp2012 (Guest)
on 2014-04-14 21:04
(Received via mailing list)
Fyi. if you are running a ssl tunnel like stunnel with openssl 0.9.x,
this
attack is logged as "SSL3_GET_RECORD:wrong version number" as opposed to
no
nginx/openssl logging.

If you have logging going back 2 years and you are seeing these log
entries
now, you may be able to detect attacks from before 7-4-2014.

Here we have many stunnels with openssl 0.9.x and found the first
attacks
at: 2014.04.08 22:19:14 (CET) in more then 2 years of logging.

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,249102,249288#msg-249288
A8108a0961c6087c43cda32c8616dcba?d=identicon&s=25 Maxim Dounin (Guest)
on 2014-04-15 13:43
(Received via mailing list)
Hello!

On Mon, Apr 14, 2014 at 03:03:54PM -0400, itpp2012 wrote:

> Fyi. if you are running a ssl tunnel like stunnel with openssl 0.9.x, this
> attack is logged as "SSL3_GET_RECORD:wrong version number" as opposed to no
> nginx/openssl logging.
>
> If you have logging going back 2 years and you are seeing these log entries
> now, you may be able to detect attacks from before 7-4-2014.
>
> Here we have many stunnels with openssl 0.9.x and found the first attacks
> at: 2014.04.08 22:19:14 (CET) in more then 2 years of logging.

I suspect that this is just a particular script to exploit the
vulnerability, which doesn't care much about being correct and
is seen this way due to incorrect handshake.  Proper exploitation
shouldn't be detectable this way.

And yes, it's seen on more or less any 0.9.x OpenSSL
installation, including nginx:

2014/04/15 04:02:57 [info] 48738#0: *2785200 SSL_do_handshake() failed
(SSL: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number)
while SSL handshaking, client: 182.118.48.115, server: 0.0.0.0:443

--
Maxim Dounin
http://nginx.org/
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.