headers
John.Airey@rnib.org.uk via RT | 1 Jul 2002 10:23
Picon
Favicon

[openssl.org #128] Submission for the openssl FAQ


Further to my previous message, I have discovered that the sentence: (They
are /lib/libssl.so.0.9.6b and  /lib/libcrypto.so.0.9.6b with symlinks
/lib/libssl.so.2 and /lib/libcrypto.so.2 respectively)

Should have read:

(eg For Red Hat 7.2 they are /lib/libssl.so.0.9.6b and
/lib/libcrypto.so.0.9.6b with symlinks /lib/libssl.so.2 and
/lib/libcrypto.so.2 respectively).

I've also doubled check the patents against the US Patent and Trademark
Office website at http://patft.uspto.gov/netahtml/srchnum.htm, and these
appear to be the correct numbers (I took them from the Red Hat openssl
source packages).

- 
John Airey
Internet systems support officer, ITCSD, Royal National Institute of the
Blind,
Bakewell Road, Peterborough PE2 6XU,
Tel.: +44 (0) 1733 375299 Fax: +44 (0) 1733 370848 John.Airey <at> rnib.org.uk 

- 

NOTICE: The information contained in this email and any attachments is 
confidential and may be legally privileged. If you are not the 
intended recipient you are hereby notified that you must not use, 
disclose, distribute, copy, print or rely on this email's content. If 
you are not the intended recipient, please notify the sender
(Continue reading)

Permalink | Reply | 0 comments |
headers
Götz Babin-Ebell | 2 Jul 2002 21:10
Picon
Favicon

Re: Update: Bull TrustWay PKCS#11 engine

afchine madjlessi wrote:
> You can find here the last updates for Trustway PKCS#11 engine.
> 
> ChangeLog:
> - patch update for openssl-engine-0.9.6d

A patch for 0.9.7 ( / HEAD) would have a greater chance to be integrated...

> Work on a generic non-intrusive version of pkcs11 engine implementation for
> openssl is in progress.

Bye

Goetz

--

-- 
Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de
Sonninstr. 24-28, 20097 Hamburg, Germany
Tel.: +49-(0)40 80 80 26 -0,  Fax: +49-(0)40 80 80 26 -126
Attachment (smime.p7s): application/x-pkcs7-signature, 2778 bytes
Permalink | Reply | 0 comments |
headers
Tim Mooney | 2 Jul 2002 21:57
Picon
Picon

openssl-0.9.6d: minor patch for shlibs on HP-UX


[I'm not subscribed to openssl-dev, please cc me on any replies]

All-

OpenSSL's platform "knowledge" continues to improve, such that shared
libraries were built by 0.9.6d when I configured it on
hppa1.1-hp-hpux10.20.

There's a very minor problem in the install process, though.  OpenSSL
wants to install shared libraries mode 644 on all UNIX platforms, but
HP-UX 9.x (I don't have 9.x anymore, but I remember the behavior) and 10.x
require that shared libraries be executable.  I don't have 11.x so I don't
know what the behavior is there, but since 11.x is ELF-based rather than
SOM-based, I would guess it's *not* required there.  Someone with access
to 11.x should confirm that, though.

In addition, for reasons that I've forgotten, it's actually a performance
hit for all applications using the library if the library is writeable
by anyone (even root).  That may not be true for more recent HP-UX
versions, but for at least some of them, the loader apparently does some
additional (likely unnecessary) work if it detects the shared library is
writeable.

For those two reasons, shared libraries on HP-UX through at least 10.x
should be installed mode 555.  The patch below my sig accomplishes that,
though there may very well be a better way of going about it.  I've tested
it on a couple platforms (HP-UX, IRIX, Tru64 UNIX), but I haven't tested
it on platforms that don't build shared libraries at all (I don't think I
have any of those, though perhaps AIX 4.x would be one).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark.Daniel@wasd.vsm.com.au via RT | 3 Jul 2002 08:57
Picon
Favicon

[openssl.org #132] OpenVMS openssl-0.9.7-beta2.tar.gz


Hi (probably) Richard,

Compaq TCP/IP Services for OpenVMS Alpha Version V5.3
on a AlphaServer 1200 5/533 4MB running OpenVMS V7.3

Builds and tests OK.

When I go to build WASD against it the compiler complained SSL_LOCL.H
couldn't include "e_os.h".  I compared the 0.9.7 to previous
distributions.

1) These had E_OS.H in the [.SSL] directory as well as the top-level
package directory.  0.9.7 only has it in the top-level.

2) Previously the SSL_LOCL.H file contained ...

  ******************************
  HT_ROOT:[SRC.OPENSSL-0_9_6D.SSL]SSL_LOCL.H;1

  #include "openssl/e_os.h"

Whereas now it contains ...

  ******************************
  HT_ROOT:[SRC.OPENSSL-0_9_7-BETA2.SSL]SSL_LOCL.H;1

  #include "e_os.h"

Will I need to change my build procedures?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Levitte via RT | 3 Jul 2002 08:57
Picon
Favicon

[openssl.org #133] Re: OpenVMS openssl-0.9.7-beta2.tar.gz


In message <01KJNN388O7M8WWIBE <at> vsm.com.au> on Wed, 03 Jul 2002 11:22:46 +0930,
Mark.Daniel <at> wasd.vsm.com.au said:

Mark.Daniel> 1) These had E_OS.H in the [.SSL] directory as well as
Mark.Daniel>    the top-level package directory.  0.9.7 only has it in
Mark.Daniel>    the top-level.

E_OS.H never existed in the [.SSL] as far as I know.

Mark.Daniel> 2) Previously the SSL_LOCL.H file contained ...
Mark.Daniel> 
Mark.Daniel>   ******************************
Mark.Daniel>   HT_ROOT:[SRC.OPENSSL-0_9_6D.SSL]SSL_LOCL.H;1
Mark.Daniel> 
Mark.Daniel>   #include "openssl/e_os.h"
Mark.Daniel> 
Mark.Daniel> Whereas now it contains ...
Mark.Daniel> 
Mark.Daniel>   ******************************
Mark.Daniel>   HT_ROOT:[SRC.OPENSSL-0_9_7-BETA2.SSL]SSL_LOCL.H;1
Mark.Daniel> 
Mark.Daniel>   #include "e_os.h"
Mark.Daniel> 
Mark.Daniel> Will I need to change my build procedures?

Shall I take it you don't use the build procedure that comes with
OpenSSL?

The explanation to the change is that e_os.h is no longer installed
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tim Mooney via RT | 3 Jul 2002 09:23
Picon
Favicon

[openssl.org #134] openssl-0.9.6d: minor patch for shlibs on HP-UX


[I'm not subscribed to openssl-dev, please cc me on any replies]

All-

OpenSSL's platform "knowledge" continues to improve, such that shared
libraries were built by 0.9.6d when I configured it on
hppa1.1-hp-hpux10.20.

There's a very minor problem in the install process, though.  OpenSSL
wants to install shared libraries mode 644 on all UNIX platforms, but
HP-UX 9.x (I don't have 9.x anymore, but I remember the behavior) and 10.x
require that shared libraries be executable.  I don't have 11.x so I don't
know what the behavior is there, but since 11.x is ELF-based rather than
SOM-based, I would guess it's *not* required there.  Someone with access
to 11.x should confirm that, though.

In addition, for reasons that I've forgotten, it's actually a performance
hit for all applications using the library if the library is writeable
by anyone (even root).  That may not be true for more recent HP-UX
versions, but for at least some of them, the loader apparently does some
additional (likely unnecessary) work if it detects the shared library is
writeable.

For those two reasons, shared libraries on HP-UX through at least 10.x
should be installed mode 555.  The patch below my sig accomplishes that,
though there may very well be a better way of going about it.  I've tested
it on a couple platforms (HP-UX, IRIX, Tru64 UNIX), but I haven't tested
it on platforms that don't build shared libraries at all (I don't think I
have any of those, though perhaps AIX 4.x would be one).
(Continue reading)

Permalink | Reply | 0 comments |
headers
adria.massanet | 3 Jul 2002 13:57
Favicon

create_empty_fragment in do_ssl3_write seems to breaks renegotiation in IE 6.0

(sorry for my bad english, first one)

I'm doing some testing of openssl.
I'm realized that the 'create-empty-fragment' introduced in do_ssl3_write
[OpenSSL 0.9.6d] to avoid IV weakness causes that IE 6.0 (other versions,
too?) don't work if a client renegotiation is performed. Modifying the code
to avoid these procedure, renegotiation will work OK.

Anyone can confirm this?

Thanks!

Adrià Massanet
Safelayer Secure Communications S.A.
Edif. World Trade Center (S-4)
Moll de Barcelona s/n
08039 Barcelona (Spain)
Phone:    +34 93 508 80 90
Fax:          +34 93 508 80 91
http://www.safelayer.com

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org
Permalink | Reply | 1 comment |
headers
Jeffrey Altman | 3 Jul 2002 15:54
Favicon

CBC vulnerability workaround

Is there a summary somewhere of the changes that were made to the
SSLv3 and TLSv1 message exchanges to avoid the vulnerability in the
CBC cipher suites?

In particular, I need to know:

 . the description of the vulnerability

 . a description of the workaround

 . a summary of why the workaround should be considered valid in 
   the protocol

I have come across a large commercial user of SSL services for whom
the workaround fails.  The transmission of the data frame with no
application data generates an SSL Alert causing the application to
close the connection.  The developers of the SSL library being used
have replied that SSLv3 does not permit data frames containing no
application data.  

Can someone summarize the issues for me?

Thanks.

 Jeffrey Altman * Sr.Software Designer     Kermit 95 2.0 GUI available now!!!
 The Kermit Project  <at>  Columbia University  SSH, Secure Telnet, Secure FTP, HTTP
 http://www.kermit-project.org/            Secured with MIT Kerberos, SRP, and 
 kermit-support <at> columbia.edu               OpenSSL.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
(Continue reading)

Permalink | Reply | 1 comment |
headers
" Tom Owens " via RT | 3 Jul 2002 16:58
Picon
Favicon

[openssl.org #135] Complie Error with OpenSSL 0.9.6 on HP-UX 10.20


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org
Permalink | Reply | 0 comments |
headers
Bodo Moeller | 3 Jul 2002 17:38
Picon
Favicon

Re: CBC vulnerability workaround

On Wed, Jul 03, 2002 at 09:54:15AM -0400, Jeffrey Altman wrote:

> Is there a summary somewhere of the changes that were made to the
> SSLv3 and TLSv1 message exchanges to avoid the vulnerability in the
> CBC cipher suites?

I'm not aware of a proper summary of all the issues involved.

> In particular, I need to know:
> 
>  . the description of the vulnerability

There's something at the following URLs:

     http://www.imc.org/ietf-tls/mail-archive/msg03273.html
     http://www.imc.org/ietf-tls/mail-archive/msg03387.html

>  . a description of the workaround

From CHANGES:

  *) Implement a countermeasure against a vulnerability recently found
     in CBC ciphersuites in SSL 3.0/TLS 1.0: Send an empty fragment
     before application data chunks to avoid the use of known IVs
     with data potentially chosen by the attacker.
     [Bodo Moeller]

As the protocols don't explicitly reset CBC IVs, the IV for each block
is known in advance (it's the last ciphertext block from the previous
record).  The attack works by choosing application data with knowledge
(Continue reading)

Permalink | Reply | 0 comments |

Gmane