1.0.1b v. VMS
1. Someone posted a complaint on comp.os.vms about a missing header file: http://groups.google.com/group/comp.os.vms/browse_thread/thread/0887b1dfe5609d3f Apparently, "srtp.h" is new, and was not added to the list in "ssl/install-ssl.com", so it doesn't get put into the installation destination directory. The usual test procedure runs against the source+build tree, so a problem like this is not detected until the victim actually tries to use the stuff. I've written a DCL script which searches through all the header files in an OpenSSL "include" directory for "#include http://antinode.info/ftp/openssl/1_0_1b/vms/test_headers.com ALP $ @ test_headers.com [.1_0_1B.include] [.1_0_1B.INCLUDE]srtp.h ALP $ write sys$output $status %X10018292 ALP $ exit %X18292 %RMS-E-FNF, file not found It wouldn't hurt, either, to build and run some simple program(s) using the just-installed stuff, instead of trusting the installation scripts. (But that could miss some of the problems which test_headers.com can find.) 2. Something seems to be wrong with the 64-bit-pointer build. The last test (TEST_CMS) with the 32-bit build does this: [...] encrypted content test streaming PEM format, 128 bit RC2 key: OK encrypted content test streaming PEM format, 40 bit RC2 key: OK encrypted content test streaming PEM format, triple DES key: OK encrypted content test streaming PEM format, 128 bit AES key: OK compressed content test streaming PEM format: OK ALL TESTS SUCCESSFUL. [...] The same test with the 64-bit build does this: [...] encrypted content test streaming PEM format, 128 bit RC2 key: OK encrypted content test streaming PEM format, 40 bit RC2 key: verify error %SYSTEM-F-ABORT, abort I haven't investigated it. OpenSSL 1.0.1b 26 Apr 2012 built on: 4-MAY-2012 19:47:54.87 platform: VMS ALPHA_64 V8.3 options: bn(64,64) md2(int) rc4(ptr,int) des(ptr,risc1,16,long) idea(int) blowfish(idx) compiler: /POINTER_SIZE=64 /DEFINE=ZLIB OPENSSLDIR: N/A I didn't see this problem with: OpenSSL 1.0.0h 12 Mar 2012 built on: 14-MAR-2012 00:22:59.46 platform: VMS ALPHA_64 V8.3 options: bn(64,64) md2(int) rc4(ptr,int) des(ptr,risc1,16,long) idea(int) blowfish(idx) compiler: /POINTER_SIZE=64 /DEFINE=ZLIB OPENSSLDIR: N/A Steven M. Schweda sms@antinode-info 382 South Warwick Street(+1) 651-699-9818 Saint Paul MN 55105-2547 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Certificate Management on an Embedded System
Hello, I am integrating OpenSSL X.509 functionality to an embedded system (first use will be for SSH authentication), which presents a unique set of problems. As I stated in an earlier post, certificate revocation checking will be performed by OCSP and not CRLs due to limited storage capacity. My current implementation is up and running just fine. However due to distribution (I'm in a multi-slot chassis) and redundancy reasons I would like to move away from my flash based file system which is currently used to store my trusted and untrusted certificates (i.e., ca-bundle.crt and authorized_users2 files). Internally, I now store all of the certificates in pair of STACK_OF(X509) structures, one for trusted certs and one for untrusted. STACK_OF(X509) * my_trusted; /* Certs which would have been in ca-bundle.crt */ STACK_OF(X509) * my_untrusted; /* Certs which would have been in authorized_users2 */ Because I am removing the ca-bundle.crt and authorized_users2 files, my X509_STORE now has no way to load certificates. I get around this by supplying my certificate stacks each time I allocate a new X509_STORE_CTX: X509_STORE sshX509CACertStore; X509_STORE_CTX * pStoreCtx; ... pStoreCtx = X509_STORE_CTX_new(); X509_STORE_CTX_init (pStoreCtx, sshX509CACertStore, pX509, my_untrusted); X509_STORE_CTX_trusted_stack(pStoreCtx, my_trusted); This works fine and dandy until it comes time to verify the OCSP signing certificate. I pass my X509_STORE (which contains no cert lookup methods) and stack of trusted certs to OCSP_basic_verify() as follows: unsigned long flags = 0; i = OCSP_basic_verify(bs, my_trusted, sshX509CACertStore, flags); OCSP_basic_verify() correctly uses my "certs" to find the OCSP signing certificate's issuer, but then goes off and creates a brand new X509_STORE_CTX which can't access any of my certificates, trusted or untrusted. This causes the OCSP_basic_verify()'s subsequent call to X509_verify_cert() to fail. I have found 2 ways to "solve" this problem. First, I can bypass certificate verification altogether by setting the OCSP_TRUSTOTHER flag (and OCSP_NOINTERN as well for good measure). However, I am unsure if this is a "safe" thing to be doing. Do I lose any security by not verifying a trusted OCSP signing certificate? Second, I can remove the call to X509_STORE_CTX_trusted_stack() and instead manually feed my trusted certificates into the X509_STORE by calling X509_STORE_add_cert() each time a new certificate is added (via a command line interface - again, I am not using files for certificate storage). This adds the certificate to X509_STORE's trusted certificate cache, making them available to all X509_STORE_CTXs (including the one allocated by OCSP_basic_verify()). This raises a couple of questions: First, do I need to worry about certificates on the X509_STORE's certificate cache ever being "flushed"? Second, is there a way to remove an individual certificate from this cache, short of deleting the entire X509_STORE, allocating a new one, and then re-populating the cache? I have both the first and second implementations working, but don't know which is better or if I need to consider another option, such as defining a new X509_LOOKUP_METHOD for my memory based certificate storage. BTW, I'll be dealing with a relatively small set of trusted certificates and no CRLs, so blindly pushing all of my trusted certs onto the X509_STORE's cache shouldn't be an issue. Any guidance would be greatly appreciated. Sincerely, - Mike Siedzik Michael Siedzik | Firmware Engineer Enterasys Networks | A Siemens Enterprise Communications Company Email: msied...@enterasys.com *There is nothing more important than our customers.*
Re: OCSP question
Can you give me an example of such application? I'll take a look at it. On Fri, 2012-05-04 at 13:14 +0200, Dr. Stephen Henson wrote: > On Thu, May 03, 2012, Alexander Komyagin wrote: > > > Thanks for the note, Stephen! I'll certainly take this into account. > > If I incorporate OCSP check in check_revoked() function, which is called > > during SSL connect/handshake it would just block during connect op for a > > while, and I believe that no single service shall expect connection > > establishment to be fast. Good service will handle other connections in > > a separate thread for the sake of availability, won't it? > > > > That can also occur during a renegotiation. > > Some applications handle multiple connections in one thread using non-blocking > I/O, in that case the OCSP query would affect the progress of all connections. > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > __ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager majord...@openssl.org -- Best wishes, Alexander Komyagin __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2806] [PATCH] key exchange cipherlist labels for 8 ciphersuites (3e, 68, a4, a5, c029, c02a, c031, c032)
> [runningdoglac...@yahoo.com - Fri May 04 11:18:52 2012]: > > There are two groups of four ciphersuites that I think have mismatched > key exchange cipherlist labels. > > The first four are DH-DSS ciphersuites with which don't seem to be > enabled, but as long as they are in the table perhaps they ought to be > corrected. > This patch changes Kx in those instances from kDHr to kDHd > (ciphersuites 3e, 68, a4, a5) > > The second four are in ECDH-RSA ciphersuites which can be seen in > 1.0.1b with > openssl ciphers "kECDHe" -v | grep RSA > ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH > Enc=AESGCM(256) Mac=AEAD > ECDH-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) > Mac=SHA384 > ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH > Enc=AESGCM(128) Mac=AEAD > ECDH-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) > Mac=SHA256 > > This patch changes Kx in those instances from kECDHe to kECDHr. > (ciphersuites c029, c02a, c031, c032) > > Thanks for the patch this will be corrected. The DH-DSS ciphersuites are enabled in OpenSSL 1.0.2 and later. Fortunately this error wont affect interoperability as the signature algorithm part of the ciphersuite is not used in TLS v1.2 Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OCSP question
On Thu, May 03, 2012, Alexander Komyagin wrote: > Thanks for the note, Stephen! I'll certainly take this into account. > If I incorporate OCSP check in check_revoked() function, which is called > during SSL connect/handshake it would just block during connect op for a > while, and I believe that no single service shall expect connection > establishment to be fast. Good service will handle other connections in > a separate thread for the sake of availability, won't it? > That can also occur during a renegotiation. Some applications handle multiple connections in one thread using non-blocking I/O, in that case the OCSP query would affect the progress of all connections. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2802] Resolved: 1.0.0's SSL_OP_ALL and SSL_OP_NO_TLSv1_1
According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2806] [PATCH] key exchange cipherlist labels for 8 ciphersuites (3e, 68, a4, a5, c029, c02a, c031, c032)
There are two groups of four ciphersuites that I think have mismatched key exchange cipherlist labels. The first four are DH-DSS ciphersuites with which don't seem to be enabled, but as long as they are in the table perhaps they ought to be corrected. This patch changes Kx in those instances from kDHr to kDHd (ciphersuites 3e, 68, a4, a5) The second four are in ECDH-RSA ciphersuites which can be seen in 1.0.1b with openssl ciphers "kECDHe" -v | grep RSA ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD ECDH-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA384 ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(128) Mac=AEAD ECDH-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA256 This patch changes Kx in those instances from kECDHe to kECDHr. (ciphersuites c029, c02a, c031, c032) There are two groups of four ciphersuites that I think have mismatched key exchange cipherlist labels.The first four are DH-DSS ciphersuites with which don't seem to be enabled, but as long as they are in the table perhaps they ought to be corrected.This patch changes Kx in those instances from kDHr to kDHd (ciphersuites 3e, 68, a4, a5)The second four are in ECDH-RSA ciphersuites which can be seen in 1.0.1b withopenssl ciphers "kECDHe" -v | grep RSAECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEADECDH-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA384ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(128) Mac=AEADECDH-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA256This patch changes Kx in those instances from kECDHe to kECDHr. (ciphersuites c029, c02a, c031, c032) openssl-csuitefixdss2.patch Description: Binary data
Re: [openssl.org #2787] [PATCH] enc: compress before compress/base64 is applied
On Sat, Apr 07, 2012 at 03:39:13PM +0200, Sebastian Andrzej Siewior via RT wrote: > The command > |openssl enc -pass pass:pass -iv 0 -K 0 -S 0 -aes-256-cbc -base64 < file > > file.enc.b64 > > first performs the encryption followed by base64 encoding. That means the > output > is base64 encoded as requests. > > The command > |openssl enc -pass pass:pass -iv 0 -K 0 -S 0 -aes-256-cbc -z < file > > file.enc.z > > first performs the encryption followed by compression. That means the > encrypted > data is compressed which should not give any improvement because a good > encryption algorithm should not produce anything that can be compressed. > > The command > | openssl enc -pass pass:pass -iv 0 -K 0 -S 0 -aes-256-cbc -z -base64 < file > > file.enc.z.base64 > > first performs the encryption, followed by base64 encoding followed by > compression. The output is no longer base64 encoded as requests but compressed > by zlib. > > This patch changes the order of the individual steps to > - compress the input > - encrypt the content > - encode is as base64 > > the -d step is in reverse order. > That means the last command will produce a base64 encoded file which was > compressed before encrypted. > > The *now* created files are no longer compatible with the files created with > an earlier version of openssl if the -z option was involved. > > To get the "old" content with new binary the following step is required: > | openssl enc -d -z < file.old | \ > | openssl enc -d -aes-256-cbc > file > > where the first step simply decompresses the content and the second performs > the > decryption. > > Signed-off-by: Sebastian Andrzej Siewior ping Sebastian __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
AW: [openssl.org #2805] uplink-x86_64-pl-script error when running "ms\do_win64a" on windows 7-64bit command line
Thank you for your quick response.
> how come it's not required in all other perlasm modules?
errors do also occure in other perlasm modules, but i'am running this configure
command without asm support
which avoids calling other perlasm modules?
perl Configure debug-VC-WIN64A no-asm --prefix=x64/debug
I have two perl.exe from msys and git in my path. I have already tried it only
with strawberry perl, but the same error occured.
My batch job does the following:
...
perl Configure debug-VC-WIN64A no-asm --prefix=x64/debug
call "C:\Programme\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" amd64
call "ms\do_win64a"
nmake -f ms\ntdll.mak
nmake -f ms\ntdll.mak install
...
Sources are always unpacked with "tar zvxf openssl-1.0.1b.tar.gz", no 7-zip was
used.
There was also a patch done to mk1mf.pl in line 330
Before
($key,$val)=/^([^=]+)=(.*)/;
I added this one (problem description and workaround found in a forum)
s/\r$//; #remove carriage return too!
Because calling
call "ms\do_win64a"
also produces this error:
D:\Projects\build\src\openssl\_orig_>perl util\mk1mf.pl dll VC-WIN64A
1>ms\ntdll.mak
no rule for crypto\md4 at util\mk1mf.pl line 967.
This is apparently a known problem on executing on windows platforms?
Regards
-Ursprüngliche Nachricht-
Von: Andy Polyakov via RT [mailto:r...@openssl.org]
Gesendet: Donnerstag, 3. Mai 2012 18:22
An: ITF-EDV Kick Tobias
Cc: openssl-dev@openssl.org
Betreff: Re: [openssl.org #2805] uplink-x86_64-pl-script error when running
"ms\do_win64a" on windows 7-64bit command line
Hi,
> my testing system is:
> Openssl 1.0.1b
> Windows 7 64-bit
> Nmake compiler-environment
>
> I'am trying to build OpenSSL with the following commands as described
> in
> INSTALL.W64
>
> Perl Configure debug-VC-WIN64A --prefix=x64/debug call
> "C:\Programme\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" amd64 call
> "ms\do_win64a"
>
> The last command generates th following error:
>
> perl ms\uplink-x86_64.pl masm 1>ms\uptable.asm Can't open perl script
> "ms../crypto/perlasm/x86_64-xlate.pl": No such file or directory
>
> The problem is the missing "/" in uplink-x86_64.pl in line 5:
> open STDOUT,"| $^X ${dir}../crypto/perlasm/x86_64-xlate.pl $output";
>
> There should be a / before ../crypto
> Then ist does work.
I can't reproduce this, not with ActivePerl. I read "then is does work"
as "following compilation succeeds". But in such case, if the change is
required in uplink-x86_64.pl, how come it's not required in all other perlasm
modules? Indeed, the pattern '$0 =~ m/(.*[\/\\])[^\/\\]+$/; $dir=$1; open
STDOUT "| $^X ${dir}../etc"' is found in *all* perlasm modules. Note that
regular expression is composed to leave last delimiting / or \, whichever is
current, so that 'ms' shouldn't happen...
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: ARM Assembly Error
Hi,
> I've been trying to build aes-armv4 for an embedded ARM 9 using the
> Green Hills Software tools. In the FIPS canister, the line following
> the label .Lok ...
>
> .Lok: stmdb sp!,{r4-r12,lr}
> sub r10,r3,#fips_aes_set_encrypt_key-AES_Te-1024@ Te4
>
> gets this error:
>
> [asarm] (error) ..\Src\fips\crypto\aes\asm\aes_armv4.arm 374:
> expected a register sub r10 , r3 , fips_aes_set_encrypt_key - AES_Te - 1024
>
> Green Hills support says:
> From what I'm seeing the form of the instruction you are using
> requires that the constant fit in an 8-bit sized field.
This is a bit misleading. It's not actual constant value that has to fit
into 8 bits, but *non-zero bits* of the value. For example, 0xff000 is
fine, 0x1fe0 is fine, 0x1ff is not.
> The constant expression:
>
> fips_aes_set_encrypt_key-AES_Te-1024
>
> currently resolves to:
>
> 0xb6c-0-0x400 = 0x76c
^ This should not end with 'c', but with '0'. How do I know? There
is '.align 5' prior AES_set_encrypt_key, which means "align this point
at 2**5=32 bytes." This allows for maximum value of 0xFF<<5=8192-32 for
such constants.
> which does not fit in an 8 bit field.
>
>
> Could I have made an error in my port which could explain this?
It's possible that your assembler doesn't interpret it as 2**5, but as
just 5, naturally rounding somehow. On the other hand wouldn't it more
appropriate for your assembler to fail with "inappropriate align value"?
One can argue that one should have used .p2align in order to avoid
disambiguity. Well, initial programming starts with looking at compiler
output and assuming conservative approach, i.e. if compiler uses .align
X and means 2**X, then we better stick to it, they might know something
we don't, e.g. that there is supported assembler that doesn't implement
.p2align... BTW, also, the value of 0xb6c is too high, I get 0x780 here
with 0x380 as final value.
> If
> this file was successfully built using some ARM compiler, which one
> was it?
GNU toolchain of course. Earliest ARM binutils I have is 2.15.
What is executable format for this platform?
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
