Re: Problems with SSL_read() - SSL_ERROR_SYSCALL / EOF - SOLVED
On 11/22/04 02:20 PM, Louis LeBlanc sat at the `puter and typed:
Hey everyone. Been a long time since I've been able to spend much time
on SSL code, but here I am again.
My app is a client side HTTP/HTTPS application, and the problem that
recently showed up (more likely it was just recently noticed) is a
problem of sorts with SSL_read(). But only with some servers.
Connections to other servers work just fine.
Here's a snippet of the code giving problems:
n = SSL_read(c-data, c-buf+c-bufend, len);
if (n = 0)
{ int sslerr = ERR_get_error();
errcode = SSL_get_error(c-data, n);
if (errno) eptr = strerror(errno);
if (sslerr)
{ (void *)ERR_error_string(sslerr, errbuf); errptr = errbuf; }
switch(errcode)
{
case SSL_ERROR_SYSCALL:
/* Some kind of I/O error; */
if (DebugSSL)
{
if (sslerr) /* SSL IO error? */
{ /* SSL_13013:I:Problem in SSL_read():%s: %s:%d */
if (errptr *errptr)
ERROR(errmsgs[SSL_13013], errptr, __FILE__, __LINE__);
else
ERROR(errmsgs[SSL_13013], SSL_ERROR_SYSCALL ,
__FILE__, __LINE__);
}
else if (eptr *eptr) /* Some system error - check errno */
ERROR(errmsgs[SSL_13013], eptr, __FILE__, __LINE__);
else if (n == 0)
ERROR(errmsgs[SSL_13013], SSL_ERROR_SYSCALL/EOF ,
__FILE__, __LINE__); // XXX
else
ERROR(errmsgs[SSL_13013], SSL_ERROR_SYSCALL/SOCKET ,
__FILE__, __LINE__);
}
sslsock_shutdown(c);
return -1;
break;
. . . // leaving out unrelated error handling
}
}
The error being logged is SSL_ERROR_SYSCALL/EOF - the section marked
with XXX. Far as I can tell, this really shouldn't happen. There
appear to be no problems in the SSL_connect phase. This code snippet is
from the first read after the connection is established - the first
attempt to read the headers.
My first assumption was that I must have mishandled the error condition
somehow. I reread the manpages for SSL_read() and SSL_get_error(), and
unless I'm interpreting these pages incorrectly, I have it right in the
code above.
Also, I should note that regular browsers have no problem conecting to
the server, and my client app has no trouble connecting to other secure
servers. The problem has been occurring with my app linked to OpenSSL
0.9.7a, but is easily reproduced with 0.9.7e.
Here's the server string returned by the origin:
Server: IBM_HTTP_SERVER/1.3.19 Apache/1.3.20 (Unix)
Ok, I finally figured this one out.
It was the cipher list after all.
My initial configuration used the list [EMAIL PROTECTED], which was intended
to maximize the list of ciphers used while giving preference to weaker
ciphers - to minimize overhead. Problem is the server in question was
choking on one of them before it got the one it liked.
When I changed the cipher list to DEFAULT, it worked fine. Of course,
DEFAULT is normally defined as ALL:!ADH:RC4+RSA:+SSLv2:@STRENGTH. I
also tried a tweak to this list: ALL:RC4+RSA:+SSLv2:+ADH:@STRENGTH,
which also worked. So I'm speculating that there is some kind of hangup
with the ADH ciphers. I haven't kept up on them in the last several
years, but I seem to remember that they were nontrivial to generate
certs for and use.
So that's it. Configuration error, and nothing wrong with OpenSSL or my
code :)
Thanks Dr. Henson for providing feedback on this issue.
Lou
--
Louis LeBlanc [EMAIL PROTECTED]
Fully Funded Hobbyist, KeySlapper Extrordinaire :)
http://www.keyslapper.org ԿԬ
Live long and prosper.
-- Spock, Amok Time, stardate 3372.7
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Problems with SSL_read() - SSL_ERROR_SYSCALL / EOF - SOLVED
On 12/08/04 11:44 AM, Louis LeBlanc sat at the `puter and typed: SNIP Ok, I finally figured this one out. It was the cipher list after all. My initial configuration used the list [EMAIL PROTECTED], which was intended to maximize the list of ciphers used while giving preference to weaker ciphers - to minimize overhead. Problem is the server in question was choking on one of them before it got the one it liked. When I changed the cipher list to DEFAULT, it worked fine. Of course, DEFAULT is normally defined as ALL:!ADH:RC4+RSA:+SSLv2:@STRENGTH. I also tried a tweak to this list: ALL:RC4+RSA:+SSLv2:+ADH:@STRENGTH, which also worked. So I'm speculating that there is some kind of hangup with the ADH ciphers. I haven't kept up on them in the last several years, but I seem to remember that they were nontrivial to generate certs for and use. So that's it. Configuration error, and nothing wrong with OpenSSL or my code :) Thanks Dr. Henson for providing feedback on this issue. Turns out the client was configured even more narrowly than I initially realized. The ciphers being used were EXPORT only. Of course this leaves out the RC4+RSA ciphers altogether. Still leaves the question why OpenSSL couldn't report the fact that no cipher could be agreed upon. Is there any way I can catch that state? Lou -- Louis LeBlanc [EMAIL PROTECTED] Fully Funded Hobbyist, KeySlapper Extrordinaire :) http://www.keyslapper.org ԿԬ __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Problems with SSL_read() - SSL_ERROR_SYSCALL / EOF
On 11/24/04 02:19 PM, Louis LeBlanc sat at the `puter and typed: SNIP Have you tried connecting using s_client? I suggest you try it with -bugs and possibly also restricting the ciphersuites in use too and possibly the SSL protocols too. Now that sheds a little light. It comes through fine even without the -bugs parameter, so it looks like my app isn't handling something right. Is there something I can do prior to the SSL_read() to verify that it's set up correctly? In the meantime, I'll run back to the client code and get it to reproduce the behavior with the s_server feature. Perhaps it will be a little more verbose than the server. Wouldn't it be nice if my client were having the same problem with the s_server tool. No such luck. Here's the rundown: My client cannot successfully fetch from a particular secure server. The OpenSSL s_client tool can. My client has no problem fetching from any other secure servers, including the OpenSSL s_server tool. My client establishes the connection (socket, then SSL handshake) and sends its request headers, then gets an EOF when trying to read the response - on the very first read. I believe the server is IBM Websphere. This is a customer server, and they have assured us their logs don't indicate we ever connected - our access to this server is pretty much nonexistent. Any other ideas would be welcome. Lou -- Louis LeBlanc [EMAIL PROTECTED] Fully Funded Hobbyist, KeySlapper Extrordinaire :) http://www.keyslapper.org ԿԬ Don't go around saying the world owes you a living. The world owes you nothing. It was here first. -- Mark Twain __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Problems with SSL_read() - SSL_ERROR_SYSCALL / EOF
On 11/23/04 10:47 PM, Dr. Stephen Henson sat at the `puter and typed: On Tue, Nov 23, 2004, Louis LeBlanc wrote: SNIP Does the connection seem otherwise OK and you just get this error after all data has been transferred? Yes. The connection is established at the socket level - nonblocking initially, then the SSL connection is established. Error checking is *very* thorough in this stage, so I'm pretty sure if it comes through, everything went ok. Once the SSL connection is established, the socket is set back to blocking. Its possible that the system is being impolite and forcibly closing the connection at the socket level. You mean the server? Why would it do this with my client and not any of the browsers I've pointed at it? Once again, this is probably the only system the client can't fetch from. I don't have any trouble fetching from Apache on Linux, Solaris, FreeBSD, Windows, and no trouble fetching from IIS, Zope, or Netscape servers either. Why would IBM Apache (Websphere, I think) be any different? Thank you for the response. If this added info gives you any ideas, I'd love to hear them. Lou -- Louis LeBlanc [EMAIL PROTECTED] Fully Funded Hobbyist, KeySlapper Extrordinaire :) http://www.keyslapper.org ԿԬ Xerox does it again and again and again and ... __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Problems with SSL_read() - SSL_ERROR_SYSCALL / EOF
On 11/24/04 05:33 PM, Dr. Stephen Henson sat at the `puter and typed: On Wed, Nov 24, 2004, Louis LeBlanc wrote: On 11/23/04 10:47 PM, Dr. Stephen Henson sat at the `puter and typed: On Tue, Nov 23, 2004, Louis LeBlanc wrote: SNIP Does the connection seem otherwise OK and you just get this error after all data has been transferred? Yes. The connection is established at the socket level - nonblocking initially, then the SSL connection is established. Error checking is *very* thorough in this stage, so I'm pretty sure if it comes through, everything went ok. Once the SSL connection is established, the socket is set back to blocking. What I mean was does this error occur just after the inital connection, during the transfer of data or after all data has been transferred? Oh. Sorry. The problem occurs just after the connection is established and request headers are sent, with the very first call to SSL_read(). It looks to me like my client is trying to read the headers, and gets the EOF. Its possible that the system is being impolite and forcibly closing the connection at the socket level. You mean the server? Why would it do this with my client and not any of the browsers I've pointed at it? If the error occurs after transfer of all data then the browsers might tolerate the impoliteness. Not the case. Perhaps I'm botching something in the request . . . Not sure why it would be bad for just this one server . . . Once again, this is probably the only system the client can't fetch from. I don't have any trouble fetching from Apache on Linux, Solaris, FreeBSD, Windows, and no trouble fetching from IIS, Zope, or Netscape servers either. Why would IBM Apache (Websphere, I think) be any different? Thank you for the response. If this added info gives you any ideas, I'd love to hear them. Have you tried connecting using s_client? I suggest you try it with -bugs and possibly also restricting the ciphersuites in use too and possibly the SSL protocols too. Now that sheds a little light. It comes through fine even without the -bugs parameter, so it looks like my app isn't handling something right. Is there something I can do prior to the SSL_read() to verify that it's set up correctly? In the meantime, I'll run back to the client code and get it to reproduce the behavior with the s_server feature. Perhaps it will be a little more verbose than the server. Thanks a lot! Lou -- Louis LeBlanc [EMAIL PROTECTED] Fully Funded Hobbyist, KeySlapper Extrordinaire :) http://www.keyslapper.org ԿԬ QOTD: I drive my car quietly, for it goes without saying. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Problems with SSL_read() - SSL_ERROR_SYSCALL / EOF
On 11/22/04 02:20 PM, Louis LeBlanc sat at the `puter and typed:
Hey everyone. Been a long time since I've been able to spend much time
on SSL code, but here I am again.
My app is a client side HTTP/HTTPS application, and the problem that
recently showed up (more likely it was just recently noticed) is a
problem of sorts with SSL_read(). But only with some servers.
Connections to other servers work just fine.
Here's a snippet of the code giving problems:
n = SSL_read(c-data, c-buf+c-bufend, len);
if (n = 0)
{ int sslerr = ERR_get_error();
errcode = SSL_get_error(c-data, n);
if (errno) eptr = strerror(errno);
if (sslerr)
{ (void *)ERR_error_string(sslerr, errbuf); errptr = errbuf; }
switch(errcode)
{
case SSL_ERROR_SYSCALL:
/* Some kind of I/O error; */
if (DebugSSL)
{
if (sslerr) /* SSL IO error? */
{ /* SSL_13013:I:Problem in SSL_read():%s: %s:%d */
if (errptr *errptr)
ERROR(errmsgs[SSL_13013], errptr, __FILE__, __LINE__);
else
ERROR(errmsgs[SSL_13013], SSL_ERROR_SYSCALL ,
__FILE__, __LINE__);
}
else if (eptr *eptr) /* Some system error - check errno */
ERROR(errmsgs[SSL_13013], eptr, __FILE__, __LINE__);
else if (n == 0)
ERROR(errmsgs[SSL_13013], SSL_ERROR_SYSCALL/EOF ,
__FILE__, __LINE__); // XXX
else
ERROR(errmsgs[SSL_13013], SSL_ERROR_SYSCALL/SOCKET ,
__FILE__, __LINE__);
}
sslsock_shutdown(c);
return -1;
break;
. . . // leaving out unrelated error handling
}
}
The error being logged is SSL_ERROR_SYSCALL/EOF - the section marked
with XXX. Far as I can tell, this really shouldn't happen. There
appear to be no problems in the SSL_connect phase. This code snippet is
from the first read after the connection is established - the first
attempt to read the headers.
My first assumption was that I must have mishandled the error condition
somehow. I reread the manpages for SSL_read() and SSL_get_error(), and
unless I'm interpreting these pages incorrectly, I have it right in the
code above.
Also, I should note that regular browsers have no problem conecting to
the server, and my client app has no trouble connecting to other secure
servers. The problem has been occurring with my app linked to OpenSSL
0.9.7a, but is easily reproduced with 0.9.7e.
Here's the server string returned by the origin:
Server: IBM_HTTP_SERVER/1.3.19 Apache/1.3.20 (Unix)
Anyone have any ideas how best to debug this?
I guess there are no ideas out there. Not surprised. I've gone
through the online docs, the Rescorla book, and the O'Reilly book. No
idea, no mention of SSL_ERROR_SYSCALL, nothing. Nada.
I guess my last option is to parse the code. Still not sure that'll
tell me anything.
Once again, any and all relevant suggestions and ideas are welcome.
Lou
--
Louis LeBlanc [EMAIL PROTECTED]
Fully Funded Hobbyist, KeySlapper Extrordinaire :)
http://www.keyslapper.org ԿԬ
QOTD:
Money isn't everything, but at least it keeps the kids in touch.
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Problems with SSL_read() - SSL_ERROR_SYSCALL / EOF
Hey everyone. Been a long time since I've been able to spend much time
on SSL code, but here I am again.
My app is a client side HTTP/HTTPS application, and the problem that
recently showed up (more likely it was just recently noticed) is a
problem of sorts with SSL_read(). But only with some servers.
Connections to other servers work just fine.
Here's a snippet of the code giving problems:
n = SSL_read(c-data, c-buf+c-bufend, len);
if (n = 0)
{ int sslerr = ERR_get_error();
errcode = SSL_get_error(c-data, n);
if (errno) eptr = strerror(errno);
if (sslerr)
{ (void *)ERR_error_string(sslerr, errbuf); errptr = errbuf; }
switch(errcode)
{
case SSL_ERROR_SYSCALL:
/* Some kind of I/O error; */
if (DebugSSL)
{
if (sslerr) /* SSL IO error? */
{ /* SSL_13013:I:Problem in SSL_read():%s: %s:%d */
if (errptr *errptr)
ERROR(errmsgs[SSL_13013], errptr, __FILE__, __LINE__);
else
ERROR(errmsgs[SSL_13013], SSL_ERROR_SYSCALL ,
__FILE__, __LINE__);
}
else if (eptr *eptr) /* Some system error - check errno */
ERROR(errmsgs[SSL_13013], eptr, __FILE__, __LINE__);
else if (n == 0)
ERROR(errmsgs[SSL_13013], SSL_ERROR_SYSCALL/EOF ,
__FILE__, __LINE__); // XXX
else
ERROR(errmsgs[SSL_13013], SSL_ERROR_SYSCALL/SOCKET ,
__FILE__, __LINE__);
}
sslsock_shutdown(c);
return -1;
break;
. . . // leaving out unrelated error handling
}
}
The error being logged is SSL_ERROR_SYSCALL/EOF - the section marked
with XXX. Far as I can tell, this really shouldn't happen. There
appear to be no problems in the SSL_connect phase. This code snippet is
from the first read after the connection is established - the first
attempt to read the headers.
My first assumption was that I must have mishandled the error condition
somehow. I reread the manpages for SSL_read() and SSL_get_error(), and
unless I'm interpreting these pages incorrectly, I have it right in the
code above.
Also, I should note that regular browsers have no problem conecting to
the server, and my client app has no trouble connecting to other secure
servers. The problem has been occurring with my app linked to OpenSSL
0.9.7a, but is easily reproduced with 0.9.7e.
Here's the server string returned by the origin:
Server: IBM_HTTP_SERVER/1.3.19 Apache/1.3.20 (Unix)
Anyone have any ideas how best to debug this?
TIA
Lou
--
Louis LeBlanc [EMAIL PROTECTED]
Fully Funded Hobbyist, KeySlapper Extrordinaire :)
http://www.keyslapper.org ԿԬ
Committee, n.:
A group of men who individually can do nothing, but as a group
can decide that nothing can be done.
-- Fred Allen
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Virus spam
On 08/12/03 11:09 AM, Laurent Blume sat at the `puter and typed: Lyngmo Ted wrote: [snip] The mails contains an attachment that contains an html page containing a virus. In the original mail, the Best Regards line is also a link to a suspicious page. The mail header suggested I'm getting these from the openssl mailing list. :-( If the list is open for non member posting, I suggest we change that. I've received the same, and I agree with you that it may be a good solution to stop that. I wouldn't like my company's IT team to believe that the OpenSSL list is a virus source :-) ANY open mailing list is a potential source of spam/virus email. It's the one downfall to the venue. I haven't checked yet, but if I got this, it was caught by SpamAssassin. I never bother complaining about these things in open lists, because I understand the need for some lists to be open. Check out SA (www.spamassassin.org). It's free and very effective. Sorry for continuing the OT thread. Lou -- Louis LeBlanc [EMAIL PROTECTED] Fully Funded Hobbyist, KeySlapper Extrordinaire :) http://www.keyslapper.org ԿԬ Carson's Consolation: Nothing is ever a complete failure. It can always be used as a bad example. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Need of FBI surveilence and PC monitoring invasion protection... ie Carnovore, etc....
On 08/04/03 03:49 PM, buddy fancher sat at the `puter and typed: Hi there, I need some help from you guys. My computer mail and disk are constantly being written to and read back from an unknown source. I suggest perhaps Carnavore or something simular (FBI). This is an invasion of my civil rights and my privacy. I have had problems with the FBI trying to destroy my life before because they think they can do whatever it is they please, and are above the law. They are not above the law. If anyone can give some simple advice on this problem, it will be greatly appreciated. They think they can destroy anyone's life, and the have no one to answer to. Sincerely, Buddy Keep in mind that this may also just be some random program that has installed spyware or something like BackOrifice on your system. If you have installed Kazaa or any one of the free screensavers advertised or just spammed around, you could very easily have something watching where you go and storing that info to report later. Kazaa is pretty well known for selling advertising space based on the kind of website you visit or even a specific domain. They have been suspected of selling ads to a company that pop up from your browser when you visit their competitor. The typical surfer assumes the popup comes from the site they are visiting, and the site often loses business because of it. If the FBI were after you, they would be very unlikely to actually write to your disk, since they are more in the business of collecting info. This is probably someone making use of free storage or just looking for some useful information - that is a very common problem when someone installs an ftp server that has anonymous ftp uploads enabled by default, and forget to disable it. You can come back a week later to find you have no more space on your disk. And sometimes, the content *is* illegal, they just put it there so they can spread it around without being caught distributing it. So you probably want to google for spyware and BackOrifice remedies. Good luck. Lou -- Louis LeBlanc [EMAIL PROTECTED] Fully Funded Hobbyist, KeySlapper Extrordinaire :) http://www.keyslapper.org ԿԬ The meek shall inherit the earth; the rest of us, the Universe. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: more spam
On 07/17/03 10:06 AM, Aleix Conchillo Flaque sat at the `puter and typed: hi, i have sent a message to the list, and some anti spam software that this user ([EMAIL PROTECTED]) has installed has sent to me an email asking me to accept it if i really wanted to send the message to him. what is this? i do not want more spam. it is really annoying. anti-spam filters are good if people keeps them for themselves. i don't want to receive more email that i have not asked for. can anyone solve this? may be i'm to drastic, but i start hating all of these. regards, aleix I know this is OT, and I never engage in such discussions, but this gets right into one of my pet peeves, so here's my two cents: Was this a SpamArrest message? If so DO NOT REPLY. If you read SpamArrests fine print, it basically says that by replying, you give them permission to send you spam. I never get spamarrest messages anymore, because I placed the following in my /etc/mail/access file: spamarrest.com 550 Go Away Spamarrest! I don't need YOUR spam Apparently SpamArrest provides their service for free, and pays for it by sending spam to anyone sending mail to their customers. I also don't care for TDMA in a mailing list context either, but they're perfect for children you want to protect from some of the more explicitly natured spam - and other internet nasties. It's pretty simple to set up, as I understand it. Basically, anyone sending you email has to put a 'tag' in the subject. No tag, no delivery. Plain and simple. I do plan to use this for my daughter when she gets to that point. In the meantime, I figure if someone doesn't allow all email from a list without making everyone that sends email to it jump through hoops, they don't really want to get the information provided. Why bother joining? Seems to me this is a grotesque breach of ettiquette anyway. Besides, I haven't sent mail to the list for awhile, and I want to see if this is something other than SpamArrest - I won't get that one :) Cheers Lou -- Louis LeBlanc [EMAIL PROTECTED] Fully Funded Hobbyist, KeySlapper Extrordinaire :) http://www.keyslapper.org ԿԬ Speer's 1st Law of Proofreading: The visibility of an error is inversely proportional to the number of times you have looked at it. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
SSL_read errors - need pointer to error string descriptions
Hey folks. I've been looking thru the OpenSSL online docs for some of the error message documentation. I've found the pages for err(3), ERR_error_string(3), ERR_get_errors(3), etc. but I can't find any real description of what the messages returned by ERR_error_string(ERR_get_error(), buf);. We're getting the following on relatively rare occasions, and my Ops dept wants some idea what it is and what, if anything should be done: error:14094417:SSL routines:SSL3_READ_BYTES:sslv3 alert illegal parameter error:140943FC:SSL routines:SSL3_READ_BYTES:sslv3 alert bad record mac These are happening in the same routine, reading a line of data from the connection (after the handshake is done) and an SSL_ERROR_SSL is returned from SSL_read(). If anyone has an idea, or knows where in the docs it is discussed, I'd really appreciate the pointer. Thanks in advance Lou -- Louis LeBlanc - Software Engineer - Mirror Image Internet, Inc. http://www.mirror-image.com [EMAIL PROTECTED] Phone: 781.376.1186Fax:781.376.1110 __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL Security Altert - Remote Buffer Overflows
On 07/30/02 11:08 AM, Ben Laurie sat at the `puter and typed: SNIP Apply the attached patch to OpenSSL 0.9.6d, or upgrade to OpenSSL 0.9.6e. Recompile all applications using OpenSSL to provide SSL or TLS. SNIP So when will 0.9.6e be available? The news page claims it's there, but there's no link from the source page. Thanks Lou -- Louis LeBlanc [EMAIL PROTECTED] Fully Funded Hobbyist, KeySlapper Extrordinaire :) http://www.keyslapper.org ԿԬ QOTD: A child of 5 could understand this! Fetch me a child of 5. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL Security Altert - Remote Buffer Overflows
On 07/30/02 09:05 AM, Louis LeBlanc sat at the `puter and typed: On 07/30/02 11:08 AM, Ben Laurie sat at the `puter and typed: SNIP Apply the attached patch to OpenSSL 0.9.6d, or upgrade to OpenSSL 0.9.6e. Recompile all applications using OpenSSL to provide SSL or TLS. SNIP So when will 0.9.6e be available? The news page claims it's there, but there's no link from the source page. Uh, heh. Nevermind, I just found it. Thanks folks. L -- Louis LeBlanc [EMAIL PROTECTED] Fully Funded Hobbyist, KeySlapper Extrordinaire :) http://www.keyslapper.org ԿԬ Liar, n.: A lawyer with a roving commission. -- Ambrose Bierce, The Devil's Dictionary __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
endless loop on SSL_ERROR_WANT_X509_LOOKUP
Hey all. I'm back on the list with a little bit of confusion.
For reference, my app is using OpenSSL 0.9.6.
The problem I'm seeing is apparently caused by a read or write attempt
returning SSL_ERROR_WANT_X509_LOOKUP. My understanding of this was
that I should simply try the read or write again. Apparently I was
mistaken because the app seems to get sucked into a loop where it
continually returns the same error and continues to loop. Needless to
say, the result is a very ugly, resource gobbling, and quite painful
decline into oblivion.
Here is a little snippet:
while (len)
{
n = SSL_write(c-data, buf+p, len);
if (n = 0)
{
errcode = SSL_get_error(c-data, n);
eptr = strerror(errno);
switch(errcode)
{
case SSL_ERROR_NONE:
case SSL_ERROR_WANT_X509_LOOKUP:
/* No error, we should try the write again. */
break;
. . .
}
}
len -= n;
p += n;
}
return p;
And the verify callback routine:
int verify_callback(int ok, X509_STORE_CTX *ctx)
{
char buffer[256], errbuf[1024];
char *buf = buffer;
X509 *err_cert;
int err,depth;
int verify_error=X509_V_OK;
if (!ok)
{
err_cert = X509_STORE_CTX_get_current_cert(ctx);
err = X509_STORE_CTX_get_error(ctx);
depth= X509_STORE_CTX_get_error_depth(ctx);
X509_NAME_oneline(X509_get_subject_name(err_cert),buf,256);
sprintf(errbuf,depth=%d %s\n,depth,buf);
log_error(errbuf);
sprintf(errbuf, verify error:num=%d:%s, err,
X509_verify_cert_error_string(err));
log_error(errbuf);
if (SSLVerifyDepth depth)
{
verify_error=X509_V_ERR_CERT_CHAIN_TOO_LONG;
sprintf(errbuf,verify error:%s\n,
X509_verify_cert_error_string(verify_error));
log_error(errbuf);
}
switch (ctx-error)
{
case X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT:
X509_NAME_oneline(X509_get_issuer_name(ctx-current_cert),buf,256);
sprintf(errbuf,issuer= %s,buf);
log_error(errbuf);
break;
case X509_V_ERR_CERT_NOT_YET_VALID:
case X509_V_ERR_ERROR_IN_CERT_NOT_BEFORE_FIELD:
sprintf(errbuf,notBefore=);
MII_ASN1_TIME_print(buf, X509_get_notBefore(ctx-current_cert));
strcat(errbuf, buf);
log_error(errbuf);
break;
case X509_V_ERR_CERT_HAS_EXPIRED:
case X509_V_ERR_ERROR_IN_CERT_NOT_AFTER_FIELD:
sprintf(errbuf,notAfter=);
MII_ASN1_TIME_print(buf, X509_get_notAfter(ctx-current_cert));
strcat(errbuf, buf);
log_error(errbuf);
break;
}
}
return(ok);
}
You probably get the idea. I am using it the same way in the read.
So, what exactly is the correct method of handling this error? The
definition I was able to find is that the verification callback wants
to be called again, but I have verified the certificate, and it is
fine. The only thing I can see out of the ordinary is that it isn't a
PEM cert. It's DER encoded. Not that it should have anything to do
with that.
Anyone have any other ideas? If there is some other little tidbit of
info that might help, but I've not included, please let me know.
Thanks.
Lou
--
Louis LeBlanc [EMAIL PROTECTED]
Fully Funded Hobbyist, KeySlapper Extrordinaire :)
http://www.keyslapper.org ԿԬ
Spence's Admonition:
Never stow away on a kamikaze plane.
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: endless loop on SSL_ERROR_WANT_X509_LOOKUP
On 06/18/02 06:59 PM, Lutz Jaenicke sat at the `puter and typed: On Tue, Jun 18, 2002 at 12:10:48PM -0400, Louis LeBlanc wrote: The problem I'm seeing is apparently caused by a read or write attempt returning SSL_ERROR_WANT_X509_LOOKUP. My understanding of this was that I should simply try the read or write again. Apparently I was mistaken because the app seems to get sucked into a loop where it continually returns the same error and continues to loop. Needless to say, the result is a very ugly, resource gobbling, and quite painful decline into oblivion. SSL_ERROR_WANT_LOOKUP can only appear on client applications. It is returned, if a client_cert_cb() is installed _and_ the client_cert_cb() returns a value 0, indicating that it cannot satisfy the request for a client certificate now and wants to be called again later. The manual page delivered with all version up to 0.9.6d is wrong, I have corrected it in the meantime. You mean the server is requesting a client cert from my app? This is what http://www.openssl.org/docs/ssl/SSL_get_error.html# says: SSL_ERROR_WANT_X509_LOOKUP The operation did not complete because an application callback set by SSL_CTX_set_client_cert_cb() has asked to be called again. The TLS/SSL I/O function should be called again later. Details depend on the application. This sounds pretty much like the manpage I have installed. Is this only returned during a connection, or can it be returned during an SSL_read or SSL_write attempt? Thanks Lutz. Lou -- Louis LeBlanc [EMAIL PROTECTED] Fully Funded Hobbyist, KeySlapper Extrordinaire :) http://www.keyslapper.org ԿԬ pain, n.: One thing, at least it proves that you're alive! __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Need clarification on SSL_CTX_sess*() routines
Hey Lutz. Thanks for your confirmation to my last message. Sorry to
bother everyone again, but I'm still not seeing what I expect with
this one call to see how many renegotiations I am getting.
On Sun, Nov 11, 2001 at 11:22:07PM -0500, Louis LeBlanc wrote:
. . .
Here is what I'm calling:
. . .
SSL_CTX_sess_connect_renegotiate(ssl_ctx);
. . .
SSL_CTX_sess_connect_renegotiate()
returns the number of start renegotiations in client mode.
Total number of renegotiations as a client - wether active or not.
. . .
This is what I am doing to fetch the info:
void dump_sslcache_stats()
{
charerrbuf[1024];
long intitems, cca, ccs, crr, sch;
items = SSL_CTX_sess_number(ssl_ctx);
cca = SSL_CTX_sess_connect(ssl_ctx);
ccs = SSL_CTX_sess_connect_good(ssl_ctx);
crr = SSL_CTX_sess_connect_renegotiate(ssl_ctx);
sch = SSL_CTX_sess_hits(ssl_ctx);
sprintf(errbuf, SSL session cache stats: \n \
%25ld items in the session cache.\n \
%25ld client connects (SSL_connect()).\n \
%25ld client connects that finished.\n \
%25ld client renegotiatations requested.\n \
%25ld session cache hits.,
items, cca, ccs, crr, sch);
log_error(errbuf);
}
I've configured the process to call this routine on reciept of a
SIGUSR2 signal. Here is what it looks like in the log:
2004-19:20:10 20262: thread 0: waiting for QM
2004-19:20:10 20262: thread 1: dumping state
2004-19:20:10 20262: thread 2: waiting for ICP packet
2004-19:20:10 20262: 33 threads, 3 used, 3 active
2004-19:20:10 20262: SSL session cache stats:
1 items in the session cache.
44 client connects (SSL_connect()).
44 client connects that finished.
0 client renegotiatations requested.
43 session cache hits.
This one is as expected, but then I shut down the Apache server
accepting the requests, and remove the SSL session cache file and the
semaphore file to ensure that no sessions remain cached when I restart
Apache.
So when I restart the server, and request one more item (without
having shut my client process down) I get the following:
2004-19:22:53 20262: thread 0: waiting for QM
2004-19:22:53 20262: thread 1: dumping state
2004-19:22:53 20262: thread 2: waiting for ICP packet
2004-19:22:53 20262: 33 threads, 3 used, 3 active
2004-19:22:53 20262: SSL session cache stats:
2 items in the session cache.
45 client connects (SSL_connect()).
45 client connects that finished.
0 client renegotiatations requested.
43 session cache hits.
So the only thing that looks wrong is the client renegotiations
requested.
Any idea what I'm doing wrong?
BTW, we're still running with V0.95a, if that matters.
Thanks
Lou
--
Louis LeBlanc [EMAIL PROTECTED]
Fully Funded Hobbyist, KeySlapper Extrordinaire :)
http://www.keyslapper.org ԿԬ
Reporter, n.:
A writer who guesses his way to the truth and dispels it with a
tempest of words.
-- Ambrose Bierce, The Devil's Dictionary
msg21764/pgp0.pgp
Description: PGP signature
Need clarification on SSL_CTX_sess*() routines
msg.pgp Description: PGP message
Re: Load CA IE and NetScape
On 10/11/01 01:16 PM, anil kumar sat at the `puter and typed: Hi All, I am using OpenSSL with Apache on Win32. OpenSSL 0.9.6, mod-ssl 2.8.2, Apache 1.3.19. I have generated CA using openssl. Installed CA certificate in the server by editing httpd.conf SSLCACertificatePath confsslprivate SSLCACertificateFile confsslCAcert.pem. Can any one suggest me, how to install CA certificate in browsers. Ok, but first you should know that the SSLCACertificatePath and SSLCACertificateFile directives in Apache are intended to point to a directory and file that contain CAs your server will trust when it does client authentication. It doesn't need just the CA that signed your server certificate. And the values you assign should be full paths. Check out the directives online. As for installing a cert in the browser, just put it in your servers doc tree somewhere, and request it with the browser. So long as you have the mime types defined in httpd.conf, it should present the CA cert to the browser for installation. You will then have to decide wether and for what purposes to trust the CA. HTH Lou -- Louis LeBlanc [EMAIL PROTECTED] Fully Funded Hobbyist, KeySlapper Extrordinaire :) http://acadia.ne.mediaone.net ԿԬ QOTD: Silence is the only virtue he has left. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Cert Chain
On 10/04/01 10:58 PM, Averroes sat at the `puter and typed: Hi Louis, I have a new question for you. After making the certifiate chain, Say, Root-CA -- Sub-CA -- User-Cert. I want to publish this CAuthority chain in pkcs7 file. Do you think it is the best format, if not which format do you prefere for that? And Which openssl's command do I need to use to produce this chain? Any ideas or comments will be very appreciated! Actually, you probably just want to create the chain out of the intermediate CA certificates in PEM format - don't include the keys. Here's a layout: server_cert - int_ca_1 - int_ca_2 - . . . - int_ca_n - root_ca You get the idea. Your chain file should consist of the intermediate certs int_ca_1 - int_ca_n, and in that order. The cert that signed your server should be at the top of the chain, then the cert that signed that one, etc. I'm under the impression that the root CA can be included in the chain (at the end) but is not needed. If you are running Apache, you would want to point to it in httpd.conf with the SSLCertificateChainFile directive. The root CA should be installed on the browser in question, and can be installed by serving it with the proper mime type. Your httpd.conf should have something like the following: IfDefine SSL AddType application/x-x509-ca-cert .crt AddType application/x-pkcs7-crl.crl /IfDefine Put the root ca in the html tree wherever you deem appropriate, and request it from the browser. Once you have installed it, and the cert chain is properly defined, your browser should trust the server implicitly. HTH Lou -- Louis LeBlanc [EMAIL PROTECTED] Fully Funded Hobbyist, KeySlapper Extrordinaire :) http://acadia.ne.mediaone.net ԿԬ vuja de: The feeling that you've *never*, *ever* been in this situation before. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: 2 certs with same name
On 10/03/01 05:35 PM, Lukasz Jazgar sat at the `puter and typed: MindTerm wrote: Hi DS, CA have a database to keep check the ceriticates which she issued. She can't create a new ceriticate with the name already existing in database. M.T. Hi, Another question. How to create 2 certificates with the same name? I need them for 2 web servers running on one computer with only one DNS name. Any advice? I assume these servers are listening on different ports - if not you will have problems. As for advice, why not use the same cert. It is the same machine and the same CN will be on the certs after all. If you can't do that for whatever reason, just change the OU name (organizational Unit) and make it relevant to the server you are running. HTH Lou -- Louis LeBlanc [EMAIL PROTECTED] Fully Funded Hobbyist, KeySlapper Extrordinaire :) http://acadia.ne.mediaone.net ԿԬ beta test, v: To voluntarily entrust one's data, one's livelihood and one's sanity to hardware or software intended to destroy all three. In earlier days, virgins were often selected to beta test volcanos. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: 2 certs with same name
On 10/03/01 09:03 PM, Lukasz Jazgar sat at the `puter and typed: Louis LeBlanc wrote: . . . I use iPlanet Webserver. Every instance of this server manages its own secure database of keys/certificates. Key pairs are generated internally by server and there is no possibility to import them from file. Seems a little inflexible. There must be a way to import a cert once it is signed by a CA. What format does it expect? Yes. It's a solution. But, if CA has a policy, which requires, that OU of certificate matches OU of CA? Actually this is the standard method of doing such a thing. I recently had to set up a worldwide secure service with the same CN on all servers. The solution was to set the OU based on the location of the server. All certs were VeriSign signed. I rather looking for solution such as special parameter or configuration. Like I said above, that is really what the OU is for. If there's no such solution, I have another questions. What's wrong in existance of two certificates, which differ only by serial number and public key? Why one entity cannot have two certificates? One entity can have two certs, last I remember we had something like 20, but there is no reason to do so unless they have separate purposes. Hence 'Organizational Unit' would describe a unit within the organization that has a different purpose, like serving content from DC, serving content from LA, Miami, Denver, etc.. The OU should give you a clue where, how, and possibly why content was served. HTH Lou -- Louis LeBlanc [EMAIL PROTECTED] Fully Funded Hobbyist, KeySlapper Extrordinaire :) http://acadia.ne.mediaone.net ԿԬ Katz' Law: Men and nations will act rationally when all other possibilities have been exhausted. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Re - multi-level CAs
On 10/03/01 02:17 PM, Neulinger, Nathan sat at the `puter and typed: I went had generated a csr from ca.key, sent it to UM System, had them sign it, brough it back, put it in certificate-chain-file on a httpd server, and also used ca.key and the new cert to sign a csr for that web server. (I figured generating new certificates for the servers isn't that big a deal in our case.) After I installed the UM-System root CA in my IE client, it works happy as can be, automatically does the certificate chain and validates successfully back to the root. However, on Netscape and openssl s_client, it does not work. It says something about Invalid CA. Here's the exact error: infinity(58)openssl s_client -CApath /umr/s/openssl/common/certs -connect falcon.cc.umr.edu:443 CONNECTED(0003) depth=1 [EMAIL PROTECTED]/C=US/ST=Missouri/L=Rolla/O=University of Missouri - Rolla/OU=Computing and Information Services/CN=UMR Certificate Authority verify error:num=24:invalid CA certificate verify return:0 --- Certificate chain 0 s:/C=US/ST=Missouri/L=Rolla/O=University of Missouri - Rolla/OU=Computing and Information [EMAIL PROTECTED] i:[EMAIL PROTECTED]/C=US/ST=Missouri/L=Rolla/O=University of Missouri - Rolla/OU=Computing and Information Services/CN=UMR Certificate Authority 1 s:[EMAIL PROTECTED]/C=US/ST=Missouri/L=Rolla/O=University of Missouri - Rolla/OU=Computing and Information Services/CN=UMR Certificate Authority i:[EMAIL PROTECTED]/C=US/ST=Missouri/L=Columbia/O=University of Missouri/OU=Information Technology/CN=University of Missouri Root Authority --- If I try to do 'openssl x509 -in um-root.pem -text', or on the new umr-cert.pem, it segfaults right as it's about to print out CRL locations. (I'm running 0.9.6a in case it matters.) Now, on netscape/mozilla, if I go ahead and install the new UMR CA-Cert (what's in the chain) it works just fine, but the automatic validation along the chain is not working. Any ideas? -- Nathan Hmm. Not that familiar with crl locations at this point. Next on my list. Anyone else? One thing you might want to do is check the openssl.cnf that was used to generate the UM System cert. From the error you give, I suspect it has the pathlen:0 on the basicConstraints line. In that case, the UMS cert cannot be used to sign other CAs. It will have to be regenerated from an openssl.cnf with the pathlen removed or raised to the maximum chain length they wish to permit. HTH Lou -- Louis LeBlanc [EMAIL PROTECTED] Fully Funded Hobbyist, KeySlapper Extrordinaire :) http://acadia.ne.mediaone.net ԿԬ Radioactive cats have 18 half-lives. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Root CA signing an intermediate CA - problems solved
On 09/24/01 01:38 PM, Dr S N Henson sat at the `puter and typed: Louis LeBlanc wrote: Maybe OpenSSL does it this way when it encounters a cert without a pathlen specified, but as I mentioned in an earlier message on this thread, Netscape (4.76?) for Linux (running on FreeBSD) seems to have a problem. Adding the pathlen was the final trick that made it work. Without the pathlen, I got Certificate path length constraint is invalid. In a Netscape popup. Well if the certificate is correctly encoded and pathlen is absent then it should interpret it as unlimited. This is specified in a number of places including RFC2459. If Netscape is doing otherwise then its a bug. I haven't seen that popup you mention before. If this standard Netscape 4.76 or PSM? I'd like to reproduce it and report it at some point. Uh, my bad. Actually, I am using Netscape Communicator 4.77. Not a big difference, but I know accuracy is important. I am using the Linux release on FreeBSD (Linux compat is installed). When I checked my original root cert, this is what I saw: # openssl x509 -in ca.crt -text -noout Certificate: Data: Version: 3 (0x2) Serial Number: 0 (0x0) Signature Algorithm: md5WithRSAEncryption Issuer: C=US, ST=Massachusetts, L=Woburn, O=Mirror Image Internet, OU=En gineering, CN=Louis [EMAIL PROTECTED] Validity Not Before: Oct 2 22:23:29 2000 GMT Not After : Feb 18 22:23:29 2028 GMT Subject: C=US, ST=Massachusetts, L=Woburn, O=Mirror Image Internet, OU=E ngineering, CN=Louis [EMAIL PROTECTED] Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:ac:46:35:27:20:15:fd:6d:a8:ce:bd:23:dd:77: e5:18:06:3e:87:0c:2f:b7:b9:f5:fb:5e:f8:76:1e: 4c:cc:2a:5a:a2:31:c9:65:eb:73:09:ae:56:43:68: 9c:08:7f:d7:9e:cd:4f:8c:3f:24:be:2d:94:a3:42: 25:e7:6d:64:48:e1:ad:f5:88:9c:45:dc:f4:37:c7: a9:c8:f9:56:6e:32:6a:d0:10:cc:a9:1e:12:b6:11: ca:96:6e:1c:eb:61:b9:db:af:f5:90:5d:10:3f:11: 4f:a5:05:2b:69:e3:cf:bb:7d:8c:61:1e:34:8d:ab: e9:4d:6f:9c:38:97:58:7f:2d Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Alternative Name: email:[EMAIL PROTECTED] X509v3 Basic Constraints: CA:TRUE, pathlen:0 Netscape Comment: mod_ssl generated custom CA certificate Netscape Cert Type: SSL CA Signature Algorithm: md5WithRSAEncryption 55:ed:b6:ae:d6:40:79:68:ab:8f:13:f9:cc:8c:bb:30:64:02: 15:11:45:09:dd:15:d6:9f:e8:84:a7:d4:9a:a8:09:27:a5:70: 6f:72:73:a0:36:ba:9b:ca:77:77:65:29:96:2a:86:44:f3:2f: 34:1b:67:2a:25:fe:c8:43:ea:37:0b:61:d9:f7:b3:35:71:f7: 80:fd:24:17:2c:d7:24:3d:c7:d0:da:34:6f:d8:24:cc:e3:d4: 9d:02:4c:3c:18:22:7b:8c:c8:44:ef:af:33:73:7b:cb:3e:af: 41:72:09:d9:08:1c:3b:d4:25:92:f6:5b:23:a6:f7:78:8c:57: ce:a0 Notice the X509v3 Basic Constraints. Quoting from openssl.txt: Basic constraints is a multi-valued extension that supports a CA and an optional pathlen option. The CA option takes the values true and false and pathlen takes an integer. Note if the CA option is false the pathlen option should be omitted. The pathlen parameter indicates the maximum number of CAs that can appear below this one in a chain. So if you have a CA with a pathlen of zero it can only be used to sign end user certificates and not further CAs. This all assumes that the software correctly interprets this extension of course. So according to this, it is behaving exactly as documented. Doesn't seem like a bug to me, just a bit obscure. I didn't see any description of expected behavior with CA:TRUE and the pathlen constraint ommitted. Maybe this is what you expected? If so, the reason I had trouble is that pathlen is not ommitted from a self signed cert by default. The above X509 description was a default selfsigned cert. I had to change the section in openssl.cnf to set it higher. I would be interested in knowing what behavior is expected/correct for the CA:TRUE/no pathlen situation, though. Seems to me as a matter of security, you'd want to default that to 0, not infinite. Thanks a bunch. Lou -- Louis LeBlanc [EMAIL PROTECTED] Fully Funded Hobbyist, KeySlapper Extrordinaire :) http://acadia.ne.mediaone.net ԿԬ File cabinet: A four drawer, manually activated trash compactor. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL
Re: Root CA signing an intermediate CA - problems solved
On 09/24/01 01:38 PM, Dr S N Henson sat at the `puter and typed: Well if the certificate is correctly encoded and pathlen is absent then it should interpret it as unlimited. This is specified in a number of places including RFC2459. If Netscape is doing otherwise then its a bug. I haven't seen that popup you mention before. If this standard Netscape 4.76 or PSM? I'd like to reproduce it and report it at some point. Ok, after a quick test, it appears that leaving the pathlen constraint out altogether will allow intermediate CAs in the chain (I only tested one so far). My problem arose because the *default* in the distributed openssl.cnf file specifies the pathlen as 0, meaning you can only sign server or user certs, not intermediate CAs. To be honest, it could be considered (as I mentioned in my previous post) to be somewhat of a security hole. Of course the signer should be deciding to sign a server cert or a CA explicitly, and should test it afterward, but there is an opening for some human error to be exploited at some point. Pretty thin, I know, but it should be considered. Looking at the root certs in ca-bundle.crt, distributed with mod_ssl, the following root CAs do define a pathlen: American Express Global Certificate Authority Deutsche Telekom AG GTE Corporation All of them define it to be 5. Interesting. Regards Lou -- Louis LeBlanc [EMAIL PROTECTED] Fully Funded Hobbyist, KeySlapper Extrordinaire :) http://acadia.ne.mediaone.net ԿԬ Any sufficiently advanced technology is indistinguishable from magic. -- Arthur C. Clarke __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Root CA signing an intermediate CA - problems!
On 09/21/01 12:53 PM, Dr S N Henson sat at the `puter and typed: Louis LeBlanc wrote: I am including the x509 output of my intermediate below. I notice that the CA constraint is false. Does this have anything to do with the problem? I am guessing it does, but how do I fix this? I have been all over the online docs, so I am fairly certain that I am just not seeing what's in front of me, or my antennae are just not picking up the right stations :) This is indeed a problem. With CA:FALSE the certificate is not a valid CA certificate and will be rejected by any reasonable software. By default OpenSSL will sign a certificate request using end user extensions. You can override this using the command line option -extensions to either 'ca' or 'x509' so if you include -extensions v3_ca it should work. You can also use the -signCA option to the CA.pl script in more recent versions of OpenSSL. So will this also result in setting the pathlen? I noticed on a self signed cert, CA is true, and there is also a pathlen=0 (or something to that effect). I managed to get over the CA:True problem, and even copied the appropriate extensions, but now, a server cert signed by an intermediate CA causes netscape to pop up a warning that the 'Certificate path length constraint is invalid. I am including all Intermediate CA files between the server cert and the root CA (in that order, but not including the server or root cert) in a chain.crt file which is pointed to by the SSLCertificateChain(?) directive in Apache. If I don't include directive, I simply get an unrecognized certificate popup, even though I have installed the root as trusted on my browser. I'll take a look in openssl.txt for any info on this - this helped me get over the last hurdle - but if you know offhand, I'd appreciate the pointer. Thanks a bunch for the help! Lou -- Louis LeBlanc [EMAIL PROTECTED] Fully Funded Hobbyist, KeySlapper Extrordinaire :) http://acadia.ne.mediaone.net ԿԬ All new: Parts not interchangeable with previous model. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Root CA signing an intermediate CA - problems solved
Ok, I found the solution, and thought someone else might benefit from my efforts. What I am trying to do is create a heirarchy of intermediate CAs with a single root CA at the top. I wish to be able to sign server certs, primarily, and they must be able to create a trusted site that loads without popup or warning on multiple browsers. Of course, having the root CA be trusted is a prerequisite, so I am installing it to the browser by simply serving it on the site with the proper mime type. As Dr Henson pointed out, the -extensions v3_ca flag would tell openssl that the cert was to be considered a CA, and CA:true would be set in the cert. However, most default self signed certs also have pathlen:0 set. This is a roadblock, and was causing my other issue: 'Certificate path length constraint is invalid. It's kinda kludgy, but here is what I did: In my openssl.cnf, I changed the following line in the v3_ca section: basicConstraints = CA:true to this: basicConstraints = CA:true,pathlen:5 which is obviously overkill, but at least I won't have to recreate my root cert because of this. the pathlen defines how many intermediate certs can be contained in the chain between the root and server/user certs. I then created a subdir in the MYCA directory for each 'first level' intermediate CA, and copied openssl.cnf into it, decrementing the pathlen constraint, and pointing the 'dir' directive in CA_default to the subdir. Repeat as needed for up to 5 certs deep. Definitely messy, but I haven't gotten around to fine tuning the whole thing into a single config that will work with multiple CAs. When I get a chance, I'll do it. For each intermediate CA directory, I set up a script to sign certs which points to the proper config, so all I have to do is get the csr into the correct location, and './sign_cert server' will sign server.csr and output server.crt. For my purposes, right now, each intermediate subdir is contained within its 'parent CAs' dir, and each maintains its own serial number count, index listing, and newcerts store. They could essentially be placed on separate machines and continue to be used with minimum modification. Like I said, it's messy, but it works for now. Thanks for the help Dr Henson! Lou -- Louis LeBlanc [EMAIL PROTECTED] Fully Funded Hobbyist, KeySlapper Extrordinaire :) http://acadia.ne.mediaone.net ԿԬ Statistics are no substitute for judgement. -- Henry Clay __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Root CA signing an intermediate CA - problems!
Hey all. I have a problem I need to solve. I am testing an SSL client app, and Need to verify that SSL certificate chains are handled correctly. So I took my root CA cert, and used it to sign another cert. I then used that cert to sign a cert for my server. I installed the cert on my server, and installed the intermediate CA as a chain using the SSLCertificateChainFile directive in the Apache httpd.conf. Sounds right to me, and that is what the online Apache docs say to do. But . . . When I try to connect to the server via Netscape on the secure port, I get the following popup: The security library has encountered an improperly formatted DER-encoded message. Any ideas? I am including the x509 output of my intermediate below. I notice that the CA constraint is false. Does this have anything to do with the problem? I am guessing it does, but how do I fix this? I have been all over the online docs, so I am fairly certain that I am just not seeing what's in front of me, or my antennae are just not picking up the right stations :) I appreciate any help. This is what my intermediate CA looks like: $ openssl x509 -text -in Int_CA2.crt Certificate: Data: Version: 3 (0x2) Serial Number: 32 (0x20) Signature Algorithm: md5WithRSAEncryption Issuer: C=US, ST=Massachusetts, L=Woburn, O=Mirror Image Internet, OU=Engineering, CN=Louis [EMAIL PROTECTED] Validity Not Before: Sep 18 20:25:12 2001 GMT Not After : Sep 18 20:25:12 2002 GMT Subject: C=US, ST=Massachusetts, O=Mirror Image, O=Mirror Image Internet, OU=Engineering, CN=Louis LeBlanc [EMAIL PROTECTED] Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:e6:57:dd:8c:85:0c:7f:fd:28:cf:0b:af:eb:ba: 26:ef:22:79:df:33:2c:ca:74:eb:1f:0c:15:a3:45: 39:68:b9:fe:e9:f0:3c:9f:a3:f6:94:59:b4:02:b5: 6b:a9:0a:8e:9b:86:f5:1d:7c:13:f7:d2:cc:68:0c: b0:82:a9:47:90:a3:45:0f:f1:b8:6b:71:18:ff:e5: 6c:26:fd:61:7c:5b:f2:ae:97:ac:e4:5e:45:6f:14: b4:71:0d:a0:78:97:69:d5:ad:85:2f:29:58:c8:70: 06:79:bd:0f:92:3f:10:3f:f6:f1:1a:a3:94:b1:81: a3:8f:57:e7:51:24:ae:4f:8d Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 61:25:7A:4D:A2:85:95:C2:8D:6D:84:A8:D7:BB:31:7F:4A:E0:0B:04 X509v3 Authority Key Identifier: DirName:/C=US/ST=Massachusetts/L=Woburn/O=Mirror Image Internet/OU=Engineering/CN=Louis [EMAIL PROTECTED] serial:00 Signature Algorithm: md5WithRSAEncryption 2a:d5:1a:50:13:be:f4:0b:d3:25:6c:d0:89:43:4a:4c:5e:ac: 7c:41:07:71:30:6d:69:3d:de:b0:36:8d:b4:f0:0a:35:1e:c6: 47:25:80:cb:2b:3c:a6:f6:6b:09:7c:25:62:4a:5d:07:f5:4b: ed:31:a9:c3:9e:64:b9:d9:f9:23:fa:ad:37:13:7c:8b:cb:27: fe:a0:0d:35:8c:19:84:e7:a6:4b:6b:ae:df:90:0e:36:84:97: 96:45:b4:42:5c:2e:63:18:74:f6:7a:3c:b7:08:64:68:39:48: 55:ce:96:7a:14:33:7c:21:e8:d7:0f:77:37:2b:55:fa:aa:24: fe:1d Thanks Lou -- Louis LeBlanc [EMAIL PROTECTED] Fully Funded Hobbyist, KeySlapper Extrordinaire :) http://acadia.ne.mediaone.net ԿԬ QOTD: It seems to me that your antenna doesn't bring in too many stations anymore. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Wierd behavior with SSL Session cache stats - client side.
On 09/08/01 01:04 PM, Lutz Jaenicke sat at the `puter and typed: On Fri, Sep 07, 2001 at 05:39:52PM -0400, Louis LeBlanc wrote: Now I have another problem. In trying to call SSL_CTX_flush_sessions(ssl_ctx, time(0)); I am being blessed with a core dump. [output deleted] I could be wrong, but I think that negative value on the timeout is a bad thing. Anyone with some idea how that happened? It'd be a pain in the neck to have to set the timeout on each individual SSL struct, when I am using only one SSL_CTX configuration to create them all, so what is the process when a connection is created from a context? Am I misunderstanding something here, or does this look like a problem? If I should give a guess (and I am asked for one here :-): An SSL_SESSION has been freed (reference count became zero and it was actually deleted) but the list of cached sessions inside SSL_CTX was not updated successfully. I don't know whether this is due to your code. We have received a patch to improve (fix?) session list handling several days ago but no time to look into it, yet. Hmm. So does anyone know if there are any changes in the session handling between 0.9.6 and the latest release? I'll see if there is any mention in the changelogs since 0.9.6. I am not willing to swear my code isn't doing anything wrong here, but it seems the library should still do something other than dump core. But I'm sure the OpenSSL developers don't need me to tell them this. IIRC, 0.9.6b is still beta; will this patch get into that release if it turns up clean? Is this something I should be using to push an upgrade to the latest release? My FreeBSD 4.3 system has 0.9.6a in the base system. I feel pretty comfortable with that as a recommendation, but I don't know about the CM folks here. Thanks for the info. Lou -- Louis LeBlanc [EMAIL PROTECTED] Fully Funded Hobbyist, KeySlapper Extrordinaire :) http://acadia.ne.mediaone.net ԿԬ The nation that controls magnetism controls the universe. -- Chester Gould/Dick Tracy __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Wierd behavior with SSL Session cache stats - client side.
that negative value on the timeout is a bad thing. Anyone with some idea how that happened? It'd be a pain in the neck to have to set the timeout on each individual SSL struct, when I am using only one SSL_CTX configuration to create them all, so what is the process when a connection is created from a context? Am I misunderstanding something here, or does this look like a problem? Now, look back at the ssl_ctx printout. session_timeout is set to 3600. I am specifically setting this myself to 5 minutes (300 sec) for testing purposes, with SSL_CTX_set_timeout(ssl_ctx, SSLTimeout); So why is this resetting to 1 hour? Sorry for the looong data dump, but I'm really confused as to what this means. I'll dupe this directory so I can make more traces as needed for debugging/feedback, etc. so feel free to ask questions that might shed some light. Thanks to anyone who can help with this. Lou -- Louis LeBlanc [EMAIL PROTECTED] Fully Funded Hobbyist, KeySlapper Extrordinaire :) http://acadia.ne.mediaone.net Ô¿Ô¬ If I had only known, I would have been a locksmith. -- Albert Einstein __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: starting new ssl session on previous ssl socket
On 08/12/01 07:32 AM, Avery Fay sat at the `puter and typed: Hello, I've been given a task that a previous employee at our company was unable to accomplish. Before I start I would like to ask if it is even possible. What I need to do: 1.) start a ssl session 2.) send / receive some data 3.) stop that session but keep the tcp / ip connection open 4.) start a new ssl session using that tcp / ip connection 5.) send / receive more data 6.) close the connection Both sides of the connection will know when to start the new ssl session. The reason I need to do this is somewhat complicated, but a hard requirement is that I have to keep the tcp / ip connection open and I must start a new ssl session. Can this be done? Are there any problem areas that I may run into? Thanks for your time and please CC me because I am not subscribed to the list (but may be soon if this is possible). Avery Fay How about SSL_renegotiate()? Check the archives over the last week, Eric Rescorla dealt with a rehandshaking question recently, and mentioned an article he is working on for Linux Journal. If it can be done, I'd imagine that is the way to do it. HTH Lou -- Louis LeBlanc [EMAIL PROTECTED] Fully Funded Hobbyist, KeySlapper Extrordinaire :) http://acadia.ne.mediaone.net ԿԬ We can defeat gravity. The problem is the paperwork involved. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Man in the middle attacks
You are correct about IE 5.x not checking the CRL by default, but be careful in using this. I recently found a bug with Windows 95, 98, and NT where if you checked the box in Internet Options to tell IE to verify the CRL, it would do so, but if a CRL link was provided, all other certificate verification would be bypassed - including the certificate CN/hostname comparison, making the man in the middle attack very easy to pull off. Essentially, you would think you are getting more security, but you are losing it instead. This would only work for these OS/browser combinations, but that is a hefty piece of the web surfer pie. Win2K did not have this problem. MS was notified, but I haven't checked for patches since then (I don't use IE - or Window$, if I can help it). Just thought you would want to know. L On Mon, Feb 05, 2001 at 09:12:42AM -0500, Michael T. Babcock wrote: Greg Stark wrote: The attack you are referring to is defeated by the client checking the identity that is contained in the certificate. I do not know why you are so sure that this checking is not normally done. IE and Netscape Nav. do it, for example [...] IE 5.x does not, by default, check to see if the server or signer certificate is revoked. These must be turned on in the advanced options. This is a real problem because it means an attacker can break into a web site, steal their certificates and do what they wish to do without the certificate owner able to do anything about it because they can't revoke their certificates in a meaningful way. That should be an exceptionally rare circumstance and, presuming the secret key is passphrase protected (all of ours are), still requires that the attacker steal the passphrase as well as the secret key. The certificates are useless without those. The secret key should be tougher to steal (root access on the box or maybe stored in a smart card where it can be used but not read). The passphrase is normally only entered when the server is started. Alternatives... You could try to steal the key out of memory (where it is no longer protected) but you have to find it first, or you could trojan the box to sniff the passphrase and then force the server to restart. An advanced cracker/intruder could do it... But he's probably got better/easier things to do. Gee... If you have reached that level of authority on the box, why bother with a man in the middle attack at all? You have the end point. Game over! Drop in a root kit, hide yourself real well, and really do some REAL damage, no MITM required! You got that level of authority, trojan the web server! That's a hell of a lot easier and yields a much better return than attempting very iffy MITM attacks. That could even defeat the cases where you can NOT obtain the secret key (smart cards). The threat you describe is not a realistic threat since once an individual can achieve your base requirements (level of authority capable of stealing certificates, secret keys, and passphrases) he already has done far more damaged to you and is capable of continuing to do far more damage to you on your own box than he could with those purloined keys and certs. Not that it should be totally dismissed, mind you. PKI is intended to provide support for revocation lists and such and what you describe is a limitation in the application implimentation, not a limitation in the SSL protocol. The information (just like CN and the start and end dates) is there (well, you have to access a CRL to check for revocation). It's up to the end point application to check it and what to do with it when it fails. So... In the end, what you describe is not an SSL problem but an application problem. Just like Kurt Seifert's paper describes MITM attacks that depend on user stupidity (ignoring warnings about CN not matching or expired or unknown CA). The cryptography and the protocols are fine. It's what we do with them as end users. As Bruce Schneier likes to say "If you believe that cryptography can solve your problem, you don't understand your problem and you don't understand cryptography." -- Michael T. Babcock (PGP: 0xBE6C1895) http://www.fibrespeed.net/~mbabcock/ Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] -- Louis LeB
Re: Rainbow Cryptoswift cards
[EMAIL PROTECTED] wrote: -Original Message- From: Louis LeBlanc [mailto:[EMAIL PROTECTED]] Sent: 19 January 2001 12:39 To: [EMAIL PROTECTED] Subject: Re: Rainbow Cryptoswift cards One quick question, just so I know how to answer when this kind of project comes up: The cryptoswift card provides 'onboard' acceleration of SSL based processing, but the card itself can only handle so many transactions per second. What happens if your traffic load exceeds the cards ability? can you easily 'spill' that extra work over to the system if you have any room there? I don't think so. All you can do is add extra cards, or run multiple servers (NetAID used 28 servers with a Rainbow card in each one). You will need to have a rough idea how much traffic you'll have, in order to estimate how many cards you'll need. Bear in mind that some of these other solutions like the Intel accelerator are based on a Rainbow card anyway. I'm hoping we can get away with one per machine. First though, I have to recompile openssl! Thanks. I guess we will have to validate the various options with our system and code base before even guessing at which option to go for. We are using our own streamlined implementation to serve content, so it is possible we will get a better cost/performance ratio without any peripherals. The backend system could wind up being overkill if we can get 500 objects/sec served without an accelerator at around $6K (give or take) and the accelerator only handling 300 effectively, we would need 2 cards to get by the 500 cps limit, but since the system is no longer performing the SSL arithmetic, it could very well be better than 60% idle. we would need to add a couple more cards to get the most out of it, but by then we could be saturating our network, and don't even get me started on the cost/performance hit with the added cost of all those cards. The specific numbers are strictly conjecture, but something to think about. Sorry to take the discussion so far off topic. L -- Louis LeBlanc Fully Funded Hobbyist, KeySlapper Extrordinaire :) [EMAIL PROTECTED] http://acadia.ne.mediaone.net __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Rainbow Cryptoswift cards
David Lang wrote: when I was evaluating similar products a couple years ago I found that it really didn't help to try and worry about spilling the load over to the main CPU. benchmarks from the time were pentium 200 linux 19 connections/sec 100% CPU RS/6000 233 (RISC) 29 connections/sec 100% CPU install SSL accelerator 300 connections/sec 10-20% CPU nowdays the raw machines will be faster, but you also need to have CPU time to run CGIs etc. I think it's unlikly that you will gain much by useing your main CPUs (assuming you get an appropriatly sized SSL accelerator We will be aiming toward a dual 880-1000Mhz system with a Gig of Ram, and using a Gigabit fiber ethernet interface. No CGI will be supported (not in the business model, we just serve cacheable content as FAST as possible). The only other overhead will be static backend database connections (possibly 100) and a few (5) other network connections. I don't think one card is going to peg those CPUs. Right now, a 440Mhz machine with 512MB of Ram is able to maintain 500+ objects served/second. The new systems will (presumably, barring any unforseen bottlenecks) be able to maintain over 1800 objects/second. We are guessing (meaning we based these numbers on 'similar but scaled' environment performance numbers), that we will need to maintain at least 600 real world new connections per second. My experience suggests that this means 2 or 3 cards that claim a 600cps ability. If these cards cost more than the system they are intended to sit on, we could just buy more of those systems (maybe even 1/card) and possibly get a better cost/performance benefit. Lots to think about. Regards Lou -- Louis LeBlanc Fully Funded Hobbyist, KeySlapper Extrordinaire :) [EMAIL PROTECTED] http://acadia.ne.mediaone.net __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Maddening problem with IE on NT or 98
Hey all. This is a problem I have been trying to solve for some time. Please read carefully, because as far as I can tell, some of these details seem to contradict others. I am only bothering you with it because I have no more ideas. We are using an Intel appliance for server side SSL session handling. Behind this appliance is a proprietary http server. We are having a strange problem fetching content with IE on Windows NT or 98. 95 is unverified at this time, and Windows 2000 does not demonstrate the problem. The version of IE does not seem relevant. Netscape does not demonstrate the problem on any platform. Using snoop, we traced the messages between the Intel appliance and the server, and found that everything was fine until the connection was established. Once the application data was supposed to start, the client just sent a TCP FIN. In another test, we put Apache/ModSSL on the server and bypassed the Intel appliance. The problem still presented in all the same scenarios. Using Eric Rescorlas ssldump, we found that the exchange does indeed get through the handshake, and fails after the server sends its Handshake Finished message. There is some "junk" then the client sends a TCP FIN. Just to make sure this wasn't some problem with the browser itself, I then pointed IE to the same icon image at my home server running the same version of Apache and ModSSL (with a couple other modules as well) and it worked fine. Below is that little bit: -- . . . 1 4 0.0620 (0.0002) SCV3.0(4) Handshake ServerHelloDone 1 5 0.1412 (0.0792) CSV3.0(68) Handshake ClientKeyExchange EncryptedPreMasterSecret[64]= ae 48 8a ef 26 20 ec 57 9d a7 4d 86 9f 2d 19 d3 d7 e1 03 30 ab 5b 43 85 85 d1 0e 92 e4 bf 0a 8f 48 8b c0 61 8f c5 ca 3d 1d 1b 84 26 f8 1a 40 74 12 4e 4a e7 f5 fe 17 bd 2f 9b f5 cb 53 ee 75 dc 1 6 0.1412 (0.) CSV3.0(1) ChangeCipherSpec 1 7 0.1412 (0.) CSV3.0(56) Handshake Finished md5_hash[16]= e1 ea 0f 78 b5 e9 c9 c8 78 6f 4b 58 15 aa db 75 sha_hash[20]= 2f 9e 32 ce 59 5b 37 c2 a8 a7 9c 64 52 bd d1 39 23 37 74 e7 1 8 0.1472 (0.0059) SCV3.0(1) ChangeCipherSpec 1 9 0.1472 (0.) SCV3.0(56) Handshake Finished md5_hash[16]= e7 da 82 93 73 0f 8f 89 c6 ff 48 fa 19 69 9d 81 sha_hash[20]= 0f 8f fa ba bf f2 c9 a9 c4 18 42 d8 80 45 e9 4e c7 10 4e 4a 10.2261 (0.0788) CS TCP FIN 1 10 0.2262 (0.0001) SCV3.0(18) Alert level warning value close_notify 10.2265 (0.0002) SC TCP FIN --- We have found that there are several cipher related issues with IE, but changing the ciphers has no effect. This problem only presented itself when we tested it in the field. Our in house lab did not present the problem at all in any browser/os combination we tried. Though configurations are the same, the problem only presents itself when we go off site. Later, trying to get an ssldump of a successful exchange, I installed Apache/ModSSL in the lab, the problem then presented itself as it did in the field. Any and all help will be greatly appreciated. Thoroughly confused. L __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Maddening problem with IE on NT or 98
Actually, IE does get through the handshake. There is a name conflict because we are going direct to a machine rather than going through a global load balancer. When there is a cert name conflict, IE warns you and will happily continue if you direct it to. Remember I said it gets through the handshake. The certs are VeriSign signed (within the last month) with an intermediate CA file installed on the secure server. If your suggestion were the case, we would not get successful content requests to our in house lab. Thanks anyway. L "Wallace, William" wrote: Are you using an SGC certificate? If so and the address you're using in the browser doesn't match that in the certificate then IE will do exactly what you've described. Recent versions let you work around it by checking "Check for server certificate revocation" in the advanced security settings. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Maddening problem with IE on NT or 98
Wait a minute! I just tried the server revocation suggestion, and it seems to work. I guess I owe you an apology for a hasty reply. Here is what I don't understand Why is this causing trouble if the cert is not expired? How can I fix this from the server side without requiring that all the surfers in the world configure their browsers? Thanks a million! Lou "Wallace, William" wrote: Are you using an SGC certificate? If so and the address you're using in the browser doesn't match that in the certificate then IE will do exactly what you've described. Recent versions let you work around it by checking "Check for server certificate revocation" in the advanced security settings. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Maddening problem with IE on NT or 98
I think I understand this. What it looks like to me is that IE gets a pointer to a revocation list and checks the cert against it. Unfortunately on NT or 98, if you don't have this checked and IE gets a pointer to a revocation list, it fails. If it is checked, it appears to just check the list and accepts the cert without caring if the cn even matches the server domain - bad. My main problem still remains. Is there a way I can solve this from the server side without calling every web surfer in the world and telling them to check that stupid box? TIA L Greg Stark wrote: IE will first try to make a connection, go through the handshake, then CLOSE the connection if it detects a problem with the certificate (or if the server asks the client to authenticate). It then prompts the user for the ok to go ahead (or prompts the user to choose a certificate to authenticate to the server with in the case of client auth), and redoes the SSL handshaking. Greg Stark, [EMAIL PROTECTED] Ethentica, Inc. www.ethentica.com - Original Message - From: "Louis LeBlanc" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 12, 2001 3:06 PM Subject: Re: Maddening problem with IE on NT or 98 Wait a minute! I just tried the server revocation suggestion, and it seems to work. I guess I owe you an apology for a hasty reply. Here is what I don't understand Why is this causing trouble if the cert is not expired? How can I fix this from the server side without requiring that all the surfers in the world configure their browsers? Thanks a million! Lou "Wallace, William" wrote: Are you using an SGC certificate? If so and the address you're using in the browser doesn't match that in the certificate then IE will do exactly what you've described. Recent versions let you work around it by checking "Check for server certificate revocation" in the advanced security settings. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] -- Louis LeBlanc Fully Funded Hobbyist, KeySlapper Extrordinaire :) [EMAIL PROTECTED] http://acadia.ne.mediaone.net __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Determining if a cipher mismatch causes a handshake error
Hey all. I am trying to determine in my client app if a handshake fails
because the client and server are not supporting any common ciphers.
In the handshake code, I have the following:
case SSL_ERROR_SSL:
/* SSL error, possibly a protocol error. */
if (DebugSSL)
{
ERR_error_string(ERR_get_error(), buf);
log_error(buf);
}
close(sock);
return 0;
break;
which is gleaned from studying docs and sample code. When we test
it with s_server using no common cipher suites, it returns the following:
error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake
failure
This is, of course only when we have a cipher mismatch - we haven't gotten
this message in any other scenario. Is there any way to get the specific
message from the OpenSSL library? or does this specific case encompass
multiple scenarios? If the latter is true, is there some way we can narrow
down this case?
TIA
Lou
--
Louis LeBlanc
Fully Funded Hobbyist, KeySlapper Extrordinaire :)
[EMAIL PROTECTED]
http://acadia.ne.mediaone.net
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Dumb question- Sorry
Slightly OT, but check out the online docs at www.apache.org, and look at VirtualHost, and .htaccess. The trick is to keep those things that are secure only in a separate directory hierarchy than those that are available on clear http. On my site, I have a separate branch at the root level for secure only, clear only, and common (accessible either way). Virtual hosts let you define different locations (Oh, yeah, pay attention to the Location directive too) and specify the filesystem path through aliases (look for that too). HTH Lou Michael Conley wrote: Did anybody have any thoughts on this? -Original Message- From: Michael Conley [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 21, 2000 10:16 PM To: '[EMAIL PROTECTED]' Subject: Dumb question- Sorry I am very new to SSL. I have set up my Apache web server on Red Hat Linux 7. I have installed OpenSSL/mod_ssl. I can now attach to the web server using either http or https. My question is how do I control which files can be accessed via http and which can only be accessed by https? I don't mind people hitting the main (home) page via http, but that will be about all I want accessible unless we move to https. How do I control which protocol can be used to access various files? I'm sure this shows my inexperience. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
SSL_peek? Need an efficient readline.
Hey, all. I am running into a problem with reading from a connection until a newline is encountered. I am unable to get a clear idea just what SSL_peek() is intended to do, which is probably the cause of my problem. I need to read from a socket, up to n bytes or until the first instance of '\n'. Now, does the SSL_peek() routine actually pull the data off the socket buffer? If I follow up with SSL_read(), will I get the same data or the data that follows what SSL_peek() returns? If it gets the data following what SSL_peek() returns, then what makes it different than SSL_read()? If there is detailed info somewhere on this call, feel free to just point it out to me. Thank you, and have a great holiday! Lou __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: bad mac decode?
Dr S N Henson wrote: What command did you use to produce that message? Were you attempting to connect to a remote server, if its is on the internet its address would help. There are several possible causes of that message such as as connecting to a server with a broken SSL/TLS implementation. Steve. I have seen this error on occasion when trying to connect to an Apache server with ModSSL. Since it uses OpenSSL, I would tend to give it the benefit of the doubt in terms of wether it is broken or not. I do not see this error all the time, one out of every couple thousand connections, maybe a little more when there is a lot of other traffic on the test network. Though I can't be sure at this point, I suspect it happens in the connect attempt. When it does show up, I always see a similar message in the Apache log. Any ideas there? Thanks in advance. Lou __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Yet another question about client side session caching . . .
Ok, I have a general idea of how to manage my own client side caching. My client already maintains a record for each server it connects to, and can store either a copy of the session, or a pointer to that session back in the SSL_CTX session cache. Which is better? I am trying to preserve the cache flushing and statistics capabilities that exist with the SSL context. If I just maintain a pointer to a session, what happens when the session is flushed - either because the whole cache was flushed or the session expired? Doesn't it turn into a pointer to oblivion? I would like to keep the sessions in the SSL_CTX cache, because flushing old sessions will be easier, and I get the session reuse stats for free. If I have to, I can just check each session when the server is accessed again, but it will mean modifications to the record maintennance routines to make sure the session is freed - not impossible, but a mild headache, anyway. I will maintain only a single connection to any server at a given time, so the timeout on the session will be quite a bit longer than the timeout on the connection - otherwise it wouldn't be much use. I may also decide to update the timestamp on the session at each access. Any and all help is, of course, greatly appreciated. Cheers Lou __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Yet another question about client side session caching . . .
Here I go responding to my own post again. Now I know why there were no answers. Seems I missed it the last time it was posted. I think I have it now. Thanks all. L Louis LeBlanc wrote: Ok, I have a general idea of how to manage my own client side caching. My client already maintains a record for each server it connects to, and can store either a copy of the session, or a pointer to that session back in the SSL_CTX session cache. Which is better? I am trying to preserve the cache flushing and statistics capabilities that exist with the SSL context. If I just maintain a pointer to a session, what happens when the session is flushed - either because the whole cache was flushed or the session expired? Doesn't it turn into a pointer to oblivion? I would like to keep the sessions in the SSL_CTX cache, because flushing old sessions will be easier, and I get the session reuse stats for free. If I have to, I can just check each session when the server is accessed again, but it will mean modifications to the record maintennance routines to make sure the session is freed - not impossible, but a mild headache, anyway. I will maintain only a single connection to any server at a given time, so the timeout on the session will be quite a bit longer than the timeout on the connection - otherwise it wouldn't be much use. I may also decide to update the timestamp on the session at each access. Any and all help is, of course, greatly appreciated. Cheers Lou __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Maybe this is a more intelligent question . .
Not so much session caching this time, but cache stats. Is there a way to reset these other than directly accessing the structure members - for instance when the cache is purged? I noticed they did not get reset when the cache gets purged using SSL_CTX_flush_sessions(ssl_ctx,0). I also did not find any library calls that cleared these explicitly. I would like these stats to reflect the number of connects, reused sessions, renegotiated sessions, etc. since the last time the session cache was empty, rather than since the process started, since it is entirely feasible for this process to run for weeks, or even months without a restart - and at high traffic operation. I don't want to overrun the variable. If there is nothing like this present, I will just have to write a call myself. TIA Lou __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: openssl 0.9.6
You might also want to use the -rand flag and provide a path to the entropy pool. You can use either egd or prngd - prngd won't block, and it provides more than enough entropy - similar to the /dev/urandom device. You will find prngd here: http://www.aet.tu-cottbus.de/personen/jaenicke/postfix_tls/prngd.html And a link to egd from there. If I remember correctly, you still have to tell OpenSSL where to find its entropy unless you have /dev/urandom or /dev/random. Even if it is only done in the openssl.cfg file. Good luck. L Doug Grove wrote: I note that it says PRNG not seeded. Is this the problem. I need to run PRNG on my HPUX box because EGD couldn't generate randomness fast enough. -Original Message- From: Zandi Patrick S TSgt AFRL/IFOSS [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Date: Wednesday, November 29, 2000 4:18 PM Subject: openssl 0.9.6 Hello, I installed EGD 0.8.0 I installed openssl 0.9.6 with egd running.. typed ./openssl req -newkey rsa:1024 -keyout key.pem -out req.pem -newhdr recieve the following error. Using configuration from /usr/local/ssl/openssl.cnf unable to load 'random state' This means that the random number generator has not been seeded with much random data. Generating a 1024 bit RSA private key 6882:error:24064064:random number generator:SSLEAY_RAND_BYTES:PRNG not seeded:md_rand.c:474:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html 6882:error:04069003:rsa routines:RSA_generate_key:BN lib:rsa_gen.c:182: --- I AM RUNNING EGD ! Why is it still Messing up.. Solaris 2.6.. Pat zandi __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Client side session caching revisited
Louis LeBlanc wrote: Hey all. I kind of feel like I'm beating a dead horse here, and that this question may have been answered already, but here goes. I have a client app that needs to connect to any number of servers and cache sessions. This app will be expected to create up to 100 connections per second, with possibly hundreds of servers being visited each minute (this is peak performance, not necessarily a constant load). Anyway, from the previous threads on the subject, I am sure I have to tell the client which session to reuse. It can't be as simple as just saying reuse the latest session ID, can it? It seems that if I go to a server, say dogs.com, the session gets cached when the connection is successful. Then if I go to cats.com, that session is cached the same way. If I then go back to dogs.com, I need to know 'this' session was for cats.com, 'that' one was for dogs.com, etc. The problem is that I can't seem to find any server specific info in the session structure - except for the cert, and this may have info that doesn't exactly match my records. Do I have to search through the entire cache for the right session, or can it be done by OpenSSL? Should I build my own cache and just copy the session into my own structure containing the connection info I need? I do understand that the SSL client has no way to know anything about where it is connecting to (of course the app should), and Lutz, I think you clarified that a bit in a previous thread on the subject. I studied some of the stunnel code, as one reader was kind enough to point me to, and it was helpful, but it really has a limited use of the cache. It actually only connects to a very few servers as a client - one per instance, I think. This makes it fundamentally different in that respect from the app I mentioned. Any help, further clarification, pointer to a howto, sample code, etc. is, as always, greatly appreciated. Lou __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] Ok, here's what I have so far: I turned on cacheing during the OpenSSL initialization in my app, then created a mechanizm to purge expired sessions every half hour. The entire cache is also purged, and stats are logged just before the logs are rolled for backup. I also added to existing signal traps the ability to force the stats logging (along with the thread status dump), purge the expired sessions (a config refresh) and purge the whole session cache (force a log roll). So it looks like the process grows at a much more controlled rate, and I have a very high degree of session reuse (up to 80 connections per session on average). However, I am not setting any sessions before SSL_connect(). It seems to be doing it on its own. I was under the impression this wouldn't happen - I just wanted to test my monitoring mechanism. The other odd thing, is that even though the number of sessions currently in the cache may drop slightly, the size of the process will continue to grow. I was under the impression that clearing expired sessions from the cache freed the memory allocated for a session. Any ideas? TIA Lou __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Client side session caching revisited
Hey all. I kind of feel like I'm beating a dead horse here, and that this question may have been answered already, but here goes. I have a client app that needs to connect to any number of servers and cache sessions. This app will be expected to create up to 100 connections per second, with possibly hundreds of servers being visited each minute (this is peak performance, not necessarily a constant load). Anyway, from the previous threads on the subject, I am sure I have to tell the client which session to reuse. It can't be as simple as just saying reuse the latest session ID, can it? It seems that if I go to a server, say dogs.com, the session gets cached when the connection is successful. Then if I go to cats.com, that session is cached the same way. If I then go back to dogs.com, I need to know 'this' session was for cats.com, 'that' one was for dogs.com, etc. The problem is that I can't seem to find any server specific info in the session structure - except for the cert, and this may have info that doesn't exactly match my records. Do I have to search through the entire cache for the right session, or can it be done by OpenSSL? Should I build my own cache and just copy the session into my own structure containing the connection info I need? I do understand that the SSL client has no way to know anything about where it is connecting to (of course the app should), and Lutz, I think you clarified that a bit in a previous thread on the subject. I studied some of the stunnel code, as one reader was kind enough to point me to, and it was helpful, but it really has a limited use of the cache. It actually only connects to a very few servers as a client - one per instance, I think. This makes it fundamentally different in that respect from the app I mentioned. Any help, further clarification, pointer to a howto, sample code, etc. is, as always, greatly appreciated. Lou __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: perl/cgi and openssl
That really depends on what you want to do. If you want your cgi script to open its own SSL connection, you need to install the perl SSL module (crypt:ssleay, or something like that - I've never used it myself). If you just want to make your script work on a secure http connection, just configure the secure site with a cgi-bin directory, and put your script there. You don't really need to do anything special. I wrote a slideshow cgi script in perl that works on both sides of my site without modification. Depending on what you want to do, of course. I suppose there are situations I am not aware of when it comes to perl and cgi. But give it a try. Worst that can happen is it won't work :) Lou "Guymon R. Hall" wrote: hi. i'm writing some perl/cgi scripts for one of my classes and would like to use openssl at some point in the near future. openssl is installed and working on the server. my question is simple: how do i get started? i've read the man page but that hasn't helped much. if you're willing to take the time to instruct me on the basics i'd appreciate it, or if you'd rather not take the time could you tell me where i can find out what the info i need (tutorials, etc.)? thanks. Guymon R. Hall 664 N. Leverett #25 Fayetteville, AR 72701 (501) 571-3448 (home) (501) 530-7904 (cell) [EMAIL PROTECTED] http://www.engr.uark.edu/~ghall --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.193 / Virus Database: 93 - Release Date: 09/19/2000 __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: verify_callback question - probably an easy one.
Lutz Jaenicke wrote: several weeks. If you are ever in the Boston Area, I owe you a beer (we have some decent American beers around here :) I don't have any special plans to come to the Boston area, but I will remember your words. (And be aware that the german type of invitation is more binding than the american one :-) Best regards, Lutz In general that may be true. But once I promise a man a beer, unless he refuses, he gets a beer! :) And I have never retracted an invitation, nor given one lightly, as I consider it a matter of honor to say what I mean and mean what I say! I look forward to meeting you if ever your travels bring you to Boston! Lou __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: verify_callback question - probably an easy one.
Ok, I think I get it now. The depth strictly relates to how many 'signings' you are removed from a root cert. I don't want to accept anything signed by someone who is also signed by a root cert, so I set my depth at 1. If I get to a root cert within that length of a cert chain, then I can check the root CA to see if i am going to trust it. So I set the preverify_ok to 1 if the chain isn't too long (verify_depth = depth), but if there are any other errors in the verification, set it back to 0 before returning it (in the switch statement). Thank you again Lutz. You have been quite helpful to me over the last several weeks. If you are ever in the Boston Area, I owe you a beer (we have some decent American beers around here :) Lou Lutz Jaenicke wrote: On Thu, Oct 19, 2000 at 03:58:26PM -0400, Louis LeBlanc wrote: I think the problem is here, in the check of verify_depth and depth: You misunderstand the verify_depth This is the format that has been suggested to me, and what is used in s_client. I am setting verify_depth to 1, and it gets verified to depth 0 when I don't have the CA cert available. It seems to me the verification process _begins_ with the peer cert, _then_ goes to the CA cert. If it cannot find the CA Cert, the 'verified' depth returns as 0. The verify_depth, of course, is 1. So shouldn't that comparison read like this: The certificate is checked at all depth levels it contains. The culprit is to check out the "ok" value handed to the verify_callback. Since last week there is a manual page available: http://www.openssl.org/docs/ssl/SSL_CTX_set_verify.html Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
errors in SSL_connect() session caching overload
Hello all. First, thanks to everyone who has helped me with any feedback on my previous problems. I seem to be pretty much over the major hurdles at this point, but I need to verify the cause of some SSL errors showing up under (very) heavy load. Here they are: error:140943FC:SSL routines:SSL3_READ_BYTES:sslv3 alert bad record mac and error:14094417:SSL routines:SSL3_READ_BYTES:sslv3 alert illegal parameter I am also getting unexpected EOF (SSL_ERROR_SYSCALL and SSL_connect returns 0). How does this occur? I am inclined to believe that they are the result of errors in the underlying sockets, but I have seen no verification of this. Can anyone give me a definitive description of the cause so I can either document it as a network issue or fix my code? Just in case anyone is interested, I have come across a problem with the SSL session caching. Under heavy load, my app would dump core, sometimes the core exceeded 300MB (though a good part of this was memory allocated for application functionality). The problem disappeared when I turned off client side session caching. I finally found in the old SSLeay.txt file a description of the session caching issues. Look for session.doc in the file. According to EAY (or whoever actually wrote the doc), teh session cache is flushed every 255 successful calls to SSL_connect(). He also says 'Please note that this could be expensive on a heavily loaded SL server, in which case, turn this off and clear the cache of old entries manually'. I suspect that the session caching is not designed to handle a large number of cached client connections. I don't know if this is a memory leak or not, but I do know that before I can use client side caching to any large degree, I will have to develop a means of monitoring and flushing the cache manually. If anyone has experience with this, a quick rundown would be greatly appreciated. Thanks Lou __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Checking an SSL connection . . .
Thank you Lutz and Steve! I used both your suggestions to get this
working.
Here is what I ended up doing:
ssl_connected = 0;
while(!ssl_connected)
{
res = SSL_connect(ssl_con);
ssl_connected = ((res == 1) SSL_is_init_finished(ssl_con));
if (!ssl_connected)
{
errcode = SSL_get_error(ssl_con, res);
switch(errcode)
{
case SSL_ERROR_NONE:
/* No error, we should have a connection, check again */
ssl_connected = ((res == 1) SSL_is_init_finished(ssl_con));
break;
case SSL_ERROR_WANT_READ:
case SSL_ERROR_WANT_WRITE:
/* no_error just wait for more data; */
pfd.fd = sock; pfd.events = POLLOUT|POLLIN; pfd.revents = 0;
while ((n = poll(pfd, 1, 1000*timeout)) 0)
{
if (errno != EINTR)
{
if (err) sprintf(err, "conn_err:%d", errno);
close(sock);
return 0;
}
}
if (!n)
{
if (err) strcpy(err, "conn_timeout");
close(sock);
return 0;
}
if ( !((pfd.revents POLLOUT) || (pfd.revents POLLIN)) )
{
if (err) strcpy(err, "connect");
close(sock);
return 0;
}
break;
case SSL_ERROR_ZERO_RETURN:
/* Peer closed the connection. */
case SSL_ERROR_SSL:
default:
/* hard_error; */
ERR_error_string(ERR_get_error(), buf);
sprintf(errbuf, "%s: %s:%d", buf, __FILE__, __LINE__);
log_error(errbuf);
close(sock);
return 0;
}
}
}
This works for me.
Thanks again.
Lou
Louis LeBlanc wrote:
Hello again, everyone.
I have solved some of the problems I have been having with setting
verification mode and depth, I think. (Thank you Lutz!)
I have also approached the problem of ensuring the connection is
successful on a nonblocking socket. What I was trying to do is use
SSL_state() to see if the connection has been made. If I interpreted
the SSL_connect()code correctly, it sets the state to
SSL_ST_CONNECT|SSL_ST_BEFORE
If I check the state with SSL_state() it should tell me if the SSL
connection has been established, right?
My initial solution was to set the connection back to blocking mode just
before the SSL_connect, and I am told it may be okay with the rest of
the app if it stays this way. Does any know of any caveats with this
scenario?
Thanks
Lou
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
SSL_peek()?
My next roadblock is in making sure that my SSL_peek() calls take nonblocking sockets into account. I understand the way SSL_read and SSL_write work, but what is the best way to make SSL_peek work correctly when the underlying socket is nonblocking? TIA Lou __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Bad record mac?
Here's an odd one. I looked in the archives, and didn't find this precise phrase anywhere. During the SSL_connect attempt, the error returned falls through to the default: case. This is the error message: error:140943FC:SSL routines:SSL3_READ_BYTES:sslv3 alert bad record mac Any idea what this means? TIA Lou __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Checking an SSL connection . . .
Hello again, everyone. I have solved some of the problems I have been having with setting verification mode and depth, I think. (Thank you Lutz!) I have also approached the problem of ensuring the connection is successful on a nonblocking socket. What I was trying to do is use SSL_state() to see if the connection has been made. If I interpreted the SSL_connect()code correctly, it sets the state to SSL_ST_CONNECT|SSL_ST_BEFORE If I check the state with SSL_state() it should tell me if the SSL connection has been established, right? My initial solution was to set the connection back to blocking mode just before the SSL_connect, and I am told it may be okay with the rest of the app if it stays this way. Does any know of any caveats with this scenario? Thanks Lou __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSL_CTX_set_verify[_depth] the second attempt
Looks good, Lutz, but I suspect you meant SSL_set_verify on line 26, rather than SSL_CTX_set_verify. Lou Lutz Jaenicke wrote: On Wed, Oct 11, 2000 at 04:24:31PM +0200, Lutz Jaenicke wrote: According to our results I have filled in the missing pieces and made changes as necessary to my draft of the corresponding manual page. Press "a" to attach before pressing "y" to send out :-) Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 SSL_CTX_set_verify.podName: SSL_CTX_set_verify.pod Type: Wordpad File (text/plain) __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Checking an SSL connection . . .
Ok, it looks like I was mistaken here. The SSL_state() does in fact return the SSL connection status flag, but it is only set to SSL_ST_CONNECT|SSL_ST_BEFORE in some cases, and only when the SSL_connect fails because the handshake didn't complete. There are nearly half a dozen states that could be set in this case. My question now is this: Is there a specific state, or (small) set of states, that I can check for on any SSL connection (for all versions) and verify that the connection is established, and ready for some kind of I/O? I found that setting the socket back to blocking is a problem. If there is any kind of glitch in the handshake (brought on by network congestion, etc) or the server has problems completing the handshake, maybe because it gets killed without prejudice, the app will sit in SSL_connect() indefinitely, without timing out. I still want to check the socket directly to get the status rather than managing my own for each connection, but it may come to that. Any comments/ideas, etc will be appreciated. Lou Louis LeBlanc wrote: Hello again, everyone. I have solved some of the problems I have been having with setting verification mode and depth, I think. (Thank you Lutz!) I have also approached the problem of ensuring the connection is successful on a nonblocking socket. What I was trying to do is use SSL_state() to see if the connection has been made. If I interpreted the SSL_connect()code correctly, it sets the state to SSL_ST_CONNECT|SSL_ST_BEFORE If I check the state with SSL_state() it should tell me if the SSL connection has been established, right? My initial solution was to set the connection back to blocking mode just before the SSL_connect, and I am told it may be okay with the rest of the app if it stays this way. Does any know of any caveats with this scenario? Thanks Lou __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Question about SSL_CTX_set_verify_depth()
Hello, All. In my attempts to learn more about the certificate verification process, I have been looking at the apps/* code, the manpages, and the release docs - not to mention the OpenSSL site. The closest thing I have found to any documentation on the SSL_CTX_set_verify_depth() routine is the following, taken from the CHANGES file in the 0.9.6 distribution: *) Support verify_depth from the SSL API. x509_vfy.c had what can be considered an off-by-one-error: Its depth (which was not part of the external interface) was actually counting the number of certificates in a chain; now it really counts the depth. [Bodo Moeller] This doesn't really tell you what it is supposed to do. Of course that isn't what a CHANGES file is for either. :) As I understand it, the verify depth associated with an SSL connection specifies the number of steps taken before verification can succeed. Any failures along the way causes a verification failure. The callback routine specified in the SSL_CTX_set_verify() call (or SSL_set_verify() for a specific connection) is required to get specific information about why the verification failed. I wonder if there is any info regarding the specifics of the verify depth, and is the call to SSL_CTX_set_verify_depth() even necessary? If not, what is being sacrificed, if anything? What are the possible values? etc. If there is documentation that spells these things out, I have been unable to find it, so please feel free to just point me to it. Searches on the list archives for SSL_CTX_set_verify_depth, set_verify_depth, and verify_depth, have not produced any messages that deal with this call specifically. TIA Lou __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Question about SSL_CTX_set_verify_depth()
Just to add to the confusion, is the callback only called when SSL_CTX_set_verify() fails a cert verification, or is it called even on a successful cert verification? I looked at the code in ssl/ssl_cert.c, and it looks like the callback in ssl_verify_cert_chain() is called regardless of the actual verification results. However, it doesn't look like this is where the cert verification takes place in my case. This routine accesses the s-ctx-app_verify_callback value, while the SSL_CTX_set_verify() call sets the ctx-default_verify_callback, and SSL_new sets s-verify_callback=ctx-default_verify_callback. A search through the entire codebase for "-verify_callback" reveals only the SSL_set*() and SSL_get*() routines in ssl/ssl_lib.c (the SSL_CTX_set*() and SSL_CTX_get*() calls set -default_verify_callback). So who knows how the callback actually occurs? I also checked the X509_V_ERR_* error definitions (crypto/x509/x509_vfy.h). I found nothing that indicated a cert/hostname mismatch. Do you have to check this the old fashioned way, or is there a way to extract this info if that is what caused the failure? I would think the latter, but I can't find it. There did not appear to be any such error definitions in crypto/x509v3 so I assume the x509v3 stuff still relies on the old x509 stuff. Any way, I guess I added quite a few questions to my previous query. I am pretty sure I made adequate attempts to find the answers myself, so either the info is not readily available or (more probably) I just don't know what to look for. Any and all help is appreciated. TIA Lou Louis LeBlanc wrote: Hello, All. In my attempts to learn more about the certificate verification process, I have been looking at the apps/* code, the manpages, and the release docs - not to mention the OpenSSL site. The closest thing I have found to any documentation on the SSL_CTX_set_verify_depth() routine is the following, taken from the CHANGES file in the 0.9.6 distribution: *) Support verify_depth from the SSL API. x509_vfy.c had what can be considered an off-by-one-error: Its depth (which was not part of the external interface) was actually counting the number of certificates in a chain; now it really counts the depth. [Bodo Moeller] This doesn't really tell you what it is supposed to do. Of course that isn't what a CHANGES file is for either. :) As I understand it, the verify depth associated with an SSL connection specifies the number of steps taken before verification can succeed. Any failures along the way causes a verification failure. The callback routine specified in the SSL_CTX_set_verify() call (or SSL_set_verify() for a specific connection) is required to get specific information about why the verification failed. I wonder if there is any info regarding the specifics of the verify depth, and is the call to SSL_CTX_set_verify_depth() even necessary? If not, what is being sacrificed, if anything? What are the possible values? etc. If there is documentation that spells these things out, I have been unable to find it, so please feel free to just point me to it. Searches on the list archives for SSL_CTX_set_verify_depth, set_verify_depth, and verify_depth, have not produced any messages that deal with this call specifically. TIA Lou __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Can't read the trusted-ca.crt file
I am working with an application that is to generate https requests, verification of the server is being done. Unfortunately, I cannot get the trusted certificate file read. This is the error message: error:02001002:system library:fopen:No such file or directory However, I am printing the certfile and path to the log as well: Using '/opt/MyAPP/test/conf/trusted-ca.crt' for CertFile. Which is assembled as follows in the code: sprintf(errbuf, "Using '%s%s' for CertFile.", dir, file); log_error(errbuf); Notice the '/' between the path and the file, the dir buffer is holding the trailing '/'. I have tried this both with and without, and as near as I can figure it isn't the problem. I have checked permissions on the file, and it is owned by the process id and group, and readable by all - and of course it is in the right place. The error I provided above is the OpenSSL error as reported by ERR_error_string(ERR_get_error(), errbuf) Does it shed any light? -- Louis LeBlanc - Software Engineer - Mirror Image Internet, Inc. http://www.mirror-image.com [EMAIL PROTECTED] Phone: 781.376.1186Fax:781.376.1110 __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Bug relating to /dev/urandom and RAND_egd in libcrypto.a
Obviously I have misunderstood the manpage for RAND_bytes. What is says
is:
int RAND_bytes(unsigned char *buf, int num);
int RAND_pseudo_bytes(unsigned char *buf, int num);
DESCRIPTION
RAND_bytes() puts num cryptographically strong pseudo-random
bytes into buf. An error occurs if the PRNG has not been
seeded with enough randomness to ensure an unpredictable
byte sequence.
. . .
This implied to me that it did in fact check the randomness. I already
admitted to being a little thick at times, so go easy on me :).
I now realize that this is not a bug, but a way to keep thick heads like
mine from resting on false security - good going guys. Now, how to
generate a 'good' seed for the PRNG.
My problem here is that this code will be installed on a large number of
systems which do not have the /dev/urandom device, and installing egd
may not be an option for so many machines . . .
I will download it anyway and check it out, but if anyone has some
reasonable way to do this from within the application, . . .
As for checking the return values of these calls, this is what I came up
with earlier:
while ( !RAND_status() )
{
bzero(entropy, CRYPT_RAND);
if (RAND_bytes(entropy, CRYPT_RAND -1) == 0)
{
ERROR("%s:%d - %s", __FILE__, __LINE__,
ERR_error_string(ERR_get_error(), err_buf) );
exit(0);
}
RAND_seed(entropy, CRYPT_RAND-1);
}
Notice that I do quit if the PRNG is under populated here. I was in the
process of finding the flaws here when I came back to find the fires
burning again on the issue.
Thanks everyone. Maybe I understand it now.
Lou
Richard Levitte - VMS Whacker wrote:
From: Louis LeBlanc [EMAIL PROTECTED]
leblanc Anyway, this is what I did:
leblanc unsigned char entropy[4096];
[...]
leblanc RAND_bytes(entropy, 4000);
leblanc RAND_seed(entropy, 3000);
And what do you think this gives you? Have you actually thought of
checking the returned status code? This is what I would call a
blatant chicken-and-egg problem.
--
Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED]
Chairman@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47
Redakteur@Stacken \ SWEDEN \ or +46-709-50 36 10
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Software Engineer, Celo Communications: http://www.celocom.com/
Unsolicited commercial email is subject to an archival fee of $400.
See http://www.stacken.kth.se/~levitte/mail/ for more info.
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Bug relating to /dev/urandom and RAND_egd in libcrypto.a
I have to admit that I am just putting my 2 cents in at the tail of this discussion, and I did miss some of the earlier posts in this thread, but my recent experience with OpenSSL client coding may shed some light here. The project involved an https load generator - primarily used for correctness testing of another project. I had the worst time getting the initial handshake to work. The dreaded 'PRNG not seeded' message kept plaguing me. Finally I did about a hundred searches on the openssl-users list archives (no, it isn't in the FAQ), and found that 0.9.5 and later have some problem seeding the handshake values if /dev/urandom does not exist (like on Solaris 2.7). The entries I found said that the current snapshots should fix it (and yes, it is a bug). I also found that a co-worker had no problem with his client and server code, but he was using 0.9.4. So I built and installed 0.9.4, 0.9.5a, and the snapshot from 6/27/2000. Then just linked the one I wanted to use to /usr/local/ssl, which my code linked through. Here is what I found: My code miraculously worked without modification when building against 0.9.4. 0.9.5a and the snapshot broke the same code at the handshake, giving the 'PRNG not seeded' message. After this, I went back to the output saved from all three builds. 0.9.4 ran through the tests without a hitch. 0.9.5a and the snapshot came up with the 'not seeded with enough data' message during the cert creation and translation tests and suggested that I set the RANDFILE environment variable - which helped exactly squat. My solution: use 0.9.4 until a new release of OpenSSL comes out that can handle a system without /dev/urandom. I have no idea how to get around that without hacking the system - which is not an option. Our code will have to run on systems that may or may not have the /dev/urandom device, so I can't use something that relies on it. Maybe stunnel isn't the problem? Try building it against 0.9.4. Just for Yuks. Louis LeBlanc Richard Levitte - VMS Whacker wrote: From: Lutz Jaenicke [EMAIL PROTECTED] Lutz.Jaenicke To the OpenSSL-Administrators: please update the Lutz.Jaenicke stunnel entry (considering this to be the new official Lutz.Jaenicke home of stunnel!?). *clicketiclick* -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Chairman@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 Redakteur@Stacken \ SWEDEN \ or +46-709-50 36 10 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, Celo Communications: http://www.celocom.com/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
