[openssl.org #189] Kerberos Ciphersuite IDs
There, I finally got the time to put this in. Just commited. Please test the next 0.9.7 snapshot and make sure I got it all right. This ticket is now resolved. [[EMAIL PROTECTED] - Mon Sep 30 18:55:14 2002]: Any chance of making progress on this? As a reminder, the issue is that the Kerberos ciphersuites in OpenSSL do not use the IDs defined in RFC2712, which obviously has negative effects on interoperability. -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #256] c_rehash - file name escape problem
Richard Levitte via RT wrote: Please test the latest snapshot and check if the solution implemented there works for you. [[EMAIL PROTECTED] - Tue Aug 27 14:12:50 2002]: Sorry for my late answer. I have tested snapshot ftp://ftp.openssl.org/snapshot/openssl-SNAP-20021009.tar.gz I founded changes like this my $fname = $_[0]; my ($hash, $fprint) = `$openssl x509 -hash -fingerprint -noout -in $fname`; This solution fails for example on file name like this bad.pem [lojza@l3tmp]$ c_rehash . Doing . sh: -c: line 1: unexpected EOF while looking for matching `' sh: -c: line 2: syntax error: unexpected end of file bad.pem = .0 I thing, that better strategy is use single quotas (') and escape char ' in file name. (my pervious solution was wrong, sorry) replace every ' by '\'' my $fname = $_[0]; $fname =~ s/'/'\\''/g; my ($hash, $fprint) = `$openssl x509 -hash -fingerprint -noout -in '$fname'`; bad.pem is now 'bad.pem' bad'.pem is now 'bad'\''.pem' Another solution should be not use quotas and escape all characters in $fname by \ my $fname = $_[0]; $fname =~ s/(.)/\\$1/g; my ($hash, $fprint) = `$openssl x509 -hash -fingerprint -noout -in $fname`; bad.pem is now \b\a\d\\.\p\e\m bad'.pem is now \b\a\d\'\.\p\e\m Thanks JFCh for an advice. Alois Vitasek __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: email vs. emailAddress (was Re: wrong defines SN_xyz)
I think that it is not a good idea to go back to the old definition. You're right; I wasn't thinking clearly yesterday :-) -- Harald Koch [EMAIL PROTECTED] It takes a child to raze a village. -Michael T. Fry __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
DES_CBC_CKSUM in SSL and Kerberos.
Title: DES_CBC_CKSUM in SSL and Kerberos. Hi, I have a customer with a Kerberos V4 application who is trying to decide if they can substitute their existing Kerberos V4 DES encryption capability with SSL's DES encryption support. When calling DES_CBC_CKSUM() from the Kerberos library, the checksum output buffer and the function's return value read : OUTBUF= 1234ABCD... // char *, 8 Byte checksum RetVal = ABCD // unsigned long, Low order(right half) 4 bytes of 8byte checksum When calling SSL's DES_CBC_CKSUM(), the values read: OUTBUF= 1234ABCD... // char *, 8 Byte checksum RetVal = DCBA // unsigned long, Low order(right half) 4 bytes of 8byte checksum SSL's RetVal produces a checksum error in the KerberosV4 application on return because it is in the oposite byte order than what Kerberos expects. The Kerberos and SSL macros used to initialize the return value from the OUTBUF follow respectively: Kerberos: #define GET_HALF_BLOCK(lr, ip) \ (lr) = ((unsigned int)(*(ip)++)) 24; \ (lr) |= ((unsigned int)(*(ip)++)) 16; \ (lr) |= ((unsigned int)(*(ip)++)) 8; \ (lr) |= (unsigned int)(*(ip)++) SSL: #define c2l(c,l) (l =((DES_LONG)(*((c)++))) , \ l|=((DES_LONG)(*((c)++))) 8L, \ l|=((DES_LONG)(*((c)++)))16L, \ l|=((DES_LONG)(*((c)++)))24L) We do not understand why SSL is swapping the bytes when initializing the output longword return value with the c2l macro in the DES_CBC_CKSUM() function. I have a test program that shows the differences. As you can see from the output below, the output is reversed between ssl and krb. $ run test_cbc_cksum set key 0 ssl 0x738af841, 0x80 0x16 0xd6 0x6b 0x41 0xf8 0x8a 0x73 krb 0x41f88a7 I then added a new macro, ksg_c2l, and had it do the same order of shifting as the get_half_block. They output is now in the correct order. $ run test_cbc_cksum2 set key 0 ssl 0x738af841, 0x80 0x16 0xd6 0x6b 0x41 0xf8 0x8a 0x73 krb 0x41f88a73 c2l 0x738af841 ksg_c2l 0x41f88a73 I have included the program with this mail message, and here are the environmental details we were operating in: OpenSSL 0.9.6b with Security patches. OpenVMS Alpha V7.2 TCP/IP V5.0A DEC C V6.2 Kerberos V4 and 5 Thanks, Kevin Kevin Greaney SSL for OpenVMS Team Hewlett Packard Company OpenVMS Engineering Group 110 Spitbrook Road Nashua, NH 03062 (603) 884-5099 test_cbc_cksum.c test_cbc_cksum.c Description: test_cbc_cksum.c
Re: DES_CBC_CKSUM in SSL and Kerberos.
The answer is: MIT DES and OpenSSL DES use different internal representations of the data. You cannot replace the MIT DES with OpenSSL DES unless you also recompile MIT Kerberos 4 to use the OpenSSL DES as well. Several people have done it in the past but it is not recommended. OpenSSL has gone to great lengths to clean the namespace so that each implementation can be used within the same application. Hi, I have a customer with a Kerberos V4 application who is trying to decide if they can substitute their existing Kerberos V4 DES encryption capability with SSL's DES encryption support. When calling DES_CBC_CKSUM() from the Kerberos library, the checksum output buffer and the function's return value read : OUTBUF=3D 1234ABCD... // char *, 8 Byte checksum RetVal =3D ABCD // unsigned long, Low order(right half) 4 bytes of 8byte checksum When calling SSL's DES_CBC_CKSUM(), the values read: OUTBUF=3D 1234ABCD... // char *, 8 Byte checksum RetVal =3D DCBA // unsigned long, Low order(right half) 4 bytes of 8byte checksum SSL's RetVal produces a checksum error in the KerberosV4 application on return because it is in the oposite byte order than what Kerberos expects. The Kerberos and SSL macros used to initialize the return value from the OUTBUF follow respectively: Kerberos: #define GET_HALF_BLOCK(lr, ip) \ (lr) =3D ((unsigned int)(*(ip)++)) 24; \ (lr) |=3D ((unsigned int)(*(ip)++)) 16; \ (lr) |=3D ((unsigned int)(*(ip)++)) 8; \ (lr) |=3D (unsigned int)(*(ip)++) =20 SSL: #define c2l(c,l) (l =3D((DES_LONG)(*((c)++))), \ l|=3D((DES_LONG)(*((c)++))) 8L, \ l|=3D((DES_LONG)(*((c)++)))16L, \ l|=3D((DES_LONG)(*((c)++)))24L) =20 We do not understand why SSL is swapping the bytes when initializing the output longword return value with the c2l macro in the DES_CBC_CKSUM() function. I have a test program that shows the differences. As you can see from the output below, the output is reversed between ssl and krb. $ run test_cbc_cksum set key 0 ssl 0x738af841, 0x80 0x16 0xd6 0x6b 0x41 0xf8 0x8a 0x73 krb 0x41f88a7 I then added a new macro, ksg_c2l, and had it do the same order of shifting as the get_half_block. They output is now in the correct order. $ run test_cbc_cksum2 set key 0 ssl 0x738af841, 0x80 0x16 0xd6 0x6b 0x41 0xf8 0x8a 0x73 krb 0x41f88a73 c2l 0x738af841 ksg_c2l 0x41f88a73 I have included the program with this mail message, and here are the environmental details=20 we were operating in: OpenSSL 0.9.6b with Security patches. OpenVMS Alpha V7.2 TCP/IP V5.0A DEC C V6.2 Kerberos V4 and 5 Thanks, Kevin =09 Kevin Greaney SSL for OpenVMS Team Hewlett Packard Company OpenVMS Engineering Group 110 Spitbrook Road =20 Nashua, NH 03062 (603) 884-5099 test_cbc_cksum.c=20 --_=_NextPart_002_01C27085.410E8F0F Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 3.2//EN HTML HEAD META HTTP-EQUIV=3DContent-Type CONTENT=3Dtext/html; = charset=3Dus-ascii META NAME=3DGenerator CONTENT=3DMS Exchange Server version = 6.0.6249.1 TITLEDES_CBC_CKSUM in SSL and Kerberos./TITLE /HEAD BODY !-- Converted from text/rtf format -- BR PFONT SIZE=3D2 FACE=3DArialnbsp;Hi,/FONT UL PFONT SIZE=3D2 FACE=3DArialnbsp;nbsp;nbsp; I have a customer = with a Kerberos V4 application who is trying to decide if they can = substitute their existing Kerberos V4 DES encryption capability with = SSL's DES encryption support.nbsp; When calling DES_CBC_CKSUM() from = the Kerberos library, the checksum output buffer and the function's = return value read :/FONT/P PFONT SIZE=3D2 FACE=3DArialnbsp;nbsp;nbsp; OUTBUF=3D = 1234ABCD...nbsp;nbsp; // char *, 8 Byte checksum/FONT BRFONT SIZE=3D2 FACE=3DArialnbsp;nbsp;nbsp; RetValnbsp;nbsp; = =3D = ABCDnbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nb= sp; // unsigned long, Low order(right half) 4 bytes of 8byte = checksum/FONT /P PFONT SIZE=3D2 FACE=3DArialnbsp;When calling SSL's = DES_CBC_CKSUM(), the values read:/FONT /P PFONT SIZE=3D2 FACE=3DArialnbsp;nbsp;nbsp; OUTBUF=3D = 1234ABCD...nbsp;nbsp; // char *, 8 Byte checksum/FONT BRFONT SIZE=3D2 FACE=3DArialnbsp;nbsp;nbsp; RetValnbsp;nbsp; = =3D = DCBAnbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nb= sp; // unsigned long, Low order(right half) 4 bytes of 8byte = checksum/FONT /P PFONT SIZE=3D2 FACE=3DArialSSL's RetVal produces a checksum error = in the
[openssl.org #302] bug report - OpenSSL 0.9.6g installed on OS/390 R2.10
We ran the 'make report' and it looks like there are some bugs. I did review Ticket #243 titled 'OpenSSL 0.9.6g fail on IBM OS/390' in the rt database. 1. Compiler: FSUM3012 Specify at least one source, archive, or object operand to be processed. This is not an issue as per the above captioned existing rt topic. 2. Failure! Has to do with selftest.pl looking for a last line in maketest.log for platform name. May be related to other issues shown below. 3. make: Makefile.ssl: line 238: Warning -- FSUM9433 Duplicate entry [../include/openssl/e_os.h] in prerequisite list We are concerned about this. 4. 2006 file=./engine_list.c, line=399, number=72, address=1C1E67C8 72 bytes leaked in 1 chunks We are concerned about this. 5. unable to load 'random state' This is not an issue as per the above captioned existing rt topic. 6. The string contains characters that are illegal for the ASN.1 type This is not an issue as per the above captioned existing rt topic. many thanks, sjm deutche bank ag (See attached file: testlog.txt) -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: DES_CBC_CKSUM in SSL and Kerberos.
Thanks very much for your reply, Jeffery. Our initial note may have led you to believe that a wholesale replacement of Kerberos encryption with SSL encryption was being considered beyond the customer's application. That was my wording error. The customer simply wants to use SSL for their application's data encryption tasks (which they manage), and so far, this is the only issue that they report (and their workaround is to simply swap the return value from SSL's DES_CBC_CKSUM call). Our follow-up question is whether DES_CBC_CKSUM() is used/required by SSL itself for its encryption processing, or if it was only provided for KRB4 application support? If it is only for KRB4/5 application support, then it looks like we need to at least re-define the c2l macro in the cbc_cksum.c module to return the correct byte order of the checksum's right-half in the longword return value. If people consider this a bugfix issue for this function, we like this suggested fix. If the DES_CBC_CKSUM() function is used by SSL for its own encryption processing, then it is presumed correct and must be left alone. Our course here is to define an equivalent function that returns the longword in the expected byte order for Kerberos callers. Lastly, note that the OUTBUF stream for both SSL and Kerberos are identical. It is only the 4 byte return value from the function that differs, so we do not seem to have any DES encryption incompatibility between SSL and Kerberos (even accepting that internal data representations are different between the two technologies). Thanks for any feedback on this! Al... -Original Message- From: Jeffrey Altman [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 10, 2002 1:56 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; Greaney, Kevin; Jamison, Alan Subject: Re: DES_CBC_CKSUM in SSL and Kerberos. The answer is: MIT DES and OpenSSL DES use different internal representations of the data. You cannot replace the MIT DES with OpenSSL DES unless you also recompile MIT Kerberos 4 to use the OpenSSL DES as well. Several people have done it in the past but it is not recommended. OpenSSL has gone to great lengths to clean the namespace so that each implementation can be used within the same application. Hi, I have a customer with a Kerberos V4 application who is trying to decide if they can substitute their existing Kerberos V4 DES encryption capability with SSL's DES encryption support. When calling DES_CBC_CKSUM() from the Kerberos library, the checksum output buffer and the function's return value read : OUTBUF=3D 1234ABCD... // char *, 8 Byte checksum RetVal =3D ABCD // unsigned long, Low order(right half) 4 bytes of 8byte checksum When calling SSL's DES_CBC_CKSUM(), the values read: OUTBUF=3D 1234ABCD... // char *, 8 Byte checksum RetVal =3D DCBA // unsigned long, Low order(right half) 4 bytes of 8byte checksum SSL's RetVal produces a checksum error in the KerberosV4 application on return because it is in the oposite byte order than what Kerberos expects. The Kerberos and SSL macros used to initialize the return value from the OUTBUF follow respectively: Kerberos: #define GET_HALF_BLOCK(lr, ip) \ (lr) =3D ((unsigned int)(*(ip)++)) 24; \ (lr) |=3D ((unsigned int)(*(ip)++)) 16; \ (lr) |=3D ((unsigned int)(*(ip)++)) 8; \ (lr) |=3D (unsigned int)(*(ip)++) =20 SSL: #define c2l(c,l) (l =3D((DES_LONG)(*((c)++))), \ l|=3D((DES_LONG)(*((c)++))) 8L, \ l|=3D((DES_LONG)(*((c)++)))16L, \ l|=3D((DES_LONG)(*((c)++)))24L) =20 We do not understand why SSL is swapping the bytes when initializing the output longword return value with the c2l macro in the DES_CBC_CKSUM() function. I have a test program that shows the differences. As you can see from the output below, the output is reversed between ssl and krb. $ run test_cbc_cksum set key 0 ssl 0x738af841, 0x80 0x16 0xd6 0x6b 0x41 0xf8 0x8a 0x73 krb 0x41f88a7 I then added a new macro, ksg_c2l, and had it do the same order of shifting as the get_half_block. They output is now in the correct order. $ run test_cbc_cksum2 set key 0 ssl 0x738af841, 0x80 0x16 0xd6 0x6b 0x41 0xf8 0x8a 0x73 krb 0x41f88a73 c2l 0x738af841 ksg_c2l 0x41f88a73 I have included the program with this mail message, and here are the environmental details=20 we were operating in: OpenSSL 0.9.6b with Security patches. OpenVMS Alpha V7.2 TCP/IP V5.0A DEC C V6.2 Kerberos V4 and 5 Thanks, Kevin =09 Kevin Greaney SSL for OpenVMS Team
Re: [openssl.org #186] Ticket Resolved
Hi I just went to the RT URL you sent me, and I'm not clear on what actually happened with my request. At some point someone posted a question which was never CC'd to me. Also I'm not sure what is the meaning of these two entries: Tue Aug 13 17:52:03 2002 jaenicke - Milestone 0.9.6h added Tue Aug 13 17:52:13 2002 jaenicke - Subsystem Build added -chris Richard Levitte via RT [EMAIL PROTECTED] writes: 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 [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #186] [PATCH] Makefile.org GNU ld detection
[[EMAIL PROTECTED] - Thu Oct 10 23:29:14 2002]: a question which was never CC'd to me. Also I'm not sure what is the meaning of these two entries: Tue Aug 13 17:52:03 2002 jaenicke - Milestone 0.9.6h added Tue Aug 13 17:52:13 2002 jaenicke - Subsystem Build added Oh, they're just keywords (kind of attributes) that were added to the entry. We use that to classify the reports we get. -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #186] [PATCH] Makefile.org GNU ld detection
So, did the patch get put in, or was it useless? -chris Richard Levitte via RT [EMAIL PROTECTED] writes: [[EMAIL PROTECTED] - Thu Oct 10 23:29:14 2002]: a question which was never CC'd to me. Also I'm not sure what is the meaning of these two entries: Tue Aug 13 17:52:03 2002 jaenicke - Milestone 0.9.6h added Tue Aug 13 17:52:13 2002 jaenicke - Subsystem Build added Oh, they're just keywords (kind of attributes) that were added to the entry. We use that to classify the reports we get. -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #186] [PATCH] Makefile.org GNU ld detection
The question was, in what way does your patch make things better? Since there was no answer for quite a while, I assumed the question wouldn't be answered, and decided to resolve the ticket. Wrongly, it now seems, so I'll reopen it and let you answer the question. [levitte - Thu Oct 10 23:42:36 2002]: [[EMAIL PROTECTED] - Thu Oct 10 23:29:14 2002]: a question which was never CC'd to me. Also I'm not sure what is the meaning of these two entries: Tue Aug 13 17:52:03 2002 jaenicke - Milestone 0.9.6h added Tue Aug 13 17:52:13 2002 jaenicke - Subsystem Build added Oh, they're just keywords (kind of attributes) that were added to the entry. We use that to classify the reports we get. -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]