[openssl-users] Forthcoming OpenSSL releases

[Matt Caswell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Forthcoming OpenSSL releases


The OpenSSL project team would like to announce the forthcoming release
of OpenSSL versions 1.0.2e, 1.0.1q, 1.0.0t and 0.9.8zh.

These releases will be made available on 3rd December between approx.
1pm and 5pm (UTC). They will fix a number of security defects, the
highest of which is classified as "moderate" severity.

Please note that the OpenSSL project has recently revised its severity
definitions by introducing a new "critical" level, i.e. the severity
levels are now: critical, high, moderate and low. Please see the
following page for further details:
https://www.openssl.org/policies/secpolicy.html

Please also note that, as per our previous announcements, the 1.0.0 and
0.9.8 releases will no longer be receiving security updates after the
end of this year. This means that, barring any unexpected significant
security issues between now and 31st December 2015, it is likely that
these releases will be the last ones for 1.0.0 and 0.9.8.

Yours

The OpenSSL Project Team
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWXG1kAAoJENnE0m0OYESR3vgH/0R7GCsN4moof7ezQIbZbxxN
qeiwH2SGj0a5KXM/J9Ee4jcQWA2n0SfUeFbgLSvqBO8BQdz3oTJMF45Z+gXjWFqZ
OiEQ+ZFayNm/Tb46OFhglbRBhfb7Je4sy4i8cSW6wGQ2EdWz3JN/xWC0q9KMqQpi
k8IwitBK3WxZ/Je+rHZvsDzABWd3Jf2+QlDjwHXxSfrW9UBc5Wr7e+d5XMQk2KML
FGJtkucAFs+AiOWvfsJ2WzFYy373M7pYQT38ODOuvT9HxMHzDY89kj2BsFjr8pZY
yIk9fAE1BTKRoNoUPETVuYi0Wq+xFHgV5urFQztxglWymcxAILHOZ+PZDyT/m5Q=
=QGvN
-END PGP SIGNATURE-
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] OpenSSL - asn1parse how to use offset-hlentgth-length

[findor]

Hi there,
I have this project on MD5 collision that I'm working on and I have a
problem understanding something. I have a certificate in DER encoding. I
need to "export" from it the header, the prefix, the public modulus etc.,
using xxd. I can't understand how exactly I have to read the data an1parse
(or dumpasn1) gives me, so I can put the right values for -s and -l to xxd.
For example, for the public modulus, I put in -s the byte where the BIT
STRING starts? or where the actual public modulus starts? And that means
that the prefix will contain everything until the point where the public
modulus starts?

The professor has given us an example of how to do it, but in the part of
the xxd commands he has given us only the commands without the structure of
the file he used.

 

 

Next question:
In the second image, why is he creating a .pfx2 with 6 bytes more, which are
from the public modulus "block"?
(Someone would think he has explained all this, but no he hasn't.)

And last question, if I understand correctly what we want to do here is that
the first thing we want to apply the MD5 collision on is the public modulus,
but instead he uses .pfx2 on fastcoll.

 

I've attached the whole file with the commands for better
understanding.X.rtf

Can anyone help?
Thanks in advance 



--
View this message in context: 
http://openssl.6102.n7.nabble.com/OpenSSL-asn1parse-how-to-use-offset-hlentgth-length-tp61324.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] long (~2.5 minute) delay in TLS handshake

[Michael Wojcik]

I'm curious if anyone has seen anything like this before.

We have a situation at one customer site. They see it happen every few days. No 
one else has reported it, and we can't reproduce it.

There's a Linux server, listening on multiple ports, handling lots of 
conversations (multiplexed with poll). Various protocols, some TLS, others not. 
Clients from many remote systems connect to this server. Some conversations are 
short-lived, others long-lived.

Four of the ports are handling Telnet (TN3270) traffic, over TLS.

Sometimes one of the ports stops responding to new conversations, from the 
client's point of view. Other clients continue to connect to other ports owned 
by the same server process; established conversations continue to work. After a 
while (maybe 15 minutes or so), the problem goes away. Note, again, that this 
only applies to new conversations on this one port. Everything else in the same 
process is happy.

A wire trace taken while the problem is occuring shows:

1. Client sends ClientHello; server stack ACKs it immediately.
2. A minute passes with no activity on the conversation.
3. Client gives up - we get a FIN from it. Server stack ACKs the FIN 
immediately.
4. Almost a minute and a half later (89 seconds in the case I'm looking at), 
the server happily sends the ServerHello. Well, that's a bit too late, and 
there's the usual crying and recriminations (RSTs from the client stack).

So nearly 2.5 minutes between ClientHello being received by the server 
machine's stack, and the ServerHello appearing on the wire. We know there's 
nothing generally wrong with the network or machines, and the processes in 
question are otherwise behaving normally.

ServerHello shows the server chose TLS_RSA_WITH_AES_256_CBC_SHA (TLS/1.0), so 
there's nothing screwy like computing DH parameters happening behind the 
covers. It's too early in the process for certificate validation callbacks to 
be invoked. Or for nearly anything else to be happening. All the server has is 
the ClientHello.

One thing I don't have at this point is any tracepoints I can have the customer 
enable to see if, say, we're getting a lot of SSL_WANT_READ or SSL_WANT_WRITE 
from SSL_accept. The socket should be in blocking mode, though it's possible 
there's some bug there.

The logic here is not exotic. It's along the lines of:
desc = accept(master, ...);
ssl = SSL_new(ctx);
SSL_set_fd(ssl, desc);
SSL_accept(ssl);

There's some setting of socket options like SO_KEEPALIVE and ex_data so we can 
recover our info in the callbacks, but really it's all pretty standard.

Any ideas?

--
Michael Wojcik
Technology Specialist, Micro Focus


Please consider the environment before printing this e-mail.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] long (~2.5 minute) delay in TLS handshake

[Kurt Roeckx]

On Mon, Nov 30, 2015 at 10:46:45PM +, Michael Wojcik wrote:
> I'm curious if anyone has seen anything like this before.
> 
> We have a situation at one customer site. They see it happen every few days. 
> No one else has reported it, and we can't reproduce it.

Have you considered that this might be a path MTU discovery issue
and that the TCP layer is just resending the (too large) packet
without it reaching the other side?


Kurt

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users