Re: Sendmail and openssl
On Wed, Sep 26, 2001, Darrin Powell wrote: I have question about using ssl for sendmail. Can you run secure email via ssl wrapper of some sort and nonsecure email no ssl wrapper at the same time? Reason being is to have both running to migrate off of regular mail to secure mail. If you don't want to use STARTTLS, then you can compile sendmail 8.12 with -D_FFR_SMTP_SSL and turn on 's' in the Modifiers of DaemonPortOptions: DAEMON_OPTIONS(`Port=465,Name=SMTPS,M=s') BTW: FFR means: For Future Release, i.e., unsupported. For STARTTLS in sendmail see: http://www.sendmail.org/~ca/email/starttls.html __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Client Authentication Problem
Eric Rescorla wrote: There are a number of situations where one wishes to authenticate clients based on their DNS names: (1) SMTP/TLS. (2) Secure remote backup. In such cases the clients often (though not always) have fixed IPs. Well, I'll be happy when IPv6 is ubiquitous (coming any day now since 1996!). Then we can dispense with kludges like DHCP and give globally unique identifiers as addresses. And what about multi-homed hosts? Or many IP addresses per host (using IP aliasing)? __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Client Authentication Problem
Eric Rescorla wrote: Götz Babin-Ebell [EMAIL PROTECTED] writes: [1 text/plain; us-ascii (7bit)] Don Zick wrote: Hello Don, I'm not actually using DNS at all. For the application I'm working with the TLS clients and servers must be statically configured with a Fully Qualified Domain Name. I match up the statically configured FQDN for a client with the DNS name from the client's certificate. You are using DNS. On the network layer you only have the IP address. To get the FQDN you need to use DNS. And compared with certificate / private key authentication it is trivial to forge a wrong DNS answer. (At least if you don't use DNSSEC on all your clients and servers...) When an attacker is able to steal a private key, he is also able to poison your DNS... I think you're misreading Don's message. He's not looking up the client's FQDN from the IP, he's extracting it from the verified certificate. It's perfectly legitimate to use this for authentication decisions and this doesn't relay on trusting the DNS. And how gets he the connection IP-Address - FQDN ? -He uses DNS. Why should he use the FQDN in the cert for any other uses ? If he wants to allow user XYZ presenting certificate C_XYZ to do some things, all he has to do is look in an internal table to map the cert to the allowed tasks. Introducing the FQDN into this is a useless layer of complexity... Note that HTTPS behaves essentially this way: you use the DNS to resolve the IP to connect to the server. You then compare the server's FQDN (as found in the certificate) against the URL. But this is to avoid trust in a possible poisoned DNS. This needs the private key secure on the server. His plan was to do it the other way round: If an attacker has obtained the private key he wants to prevent missuse with DNS. And that is broken. Bye Goetz -- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 S/MIME Cryptographic Signature
Re: Client Authentication Problem
Michael Sierchio [EMAIL PROTECTED] writes: Eric Rescorla wrote: There are a number of situations where one wishes to authenticate clients based on their DNS names: (1) SMTP/TLS. (2) Secure remote backup. In such cases the clients often (though not always) have fixed IPs. Well, I'll be happy when IPv6 is ubiquitous (coming any day now since 1996!). Then we can dispense with kludges like DHCP and give globally unique identifiers as addresses. And what about multi-homed hosts? Or many IP addresses per host (using IP aliasing)? I don't see that any of these are really an issue here. The client's IP address isn't being examined at all. The DNS name is simply being used as a unique identifier. -Ekr __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Client Authentication Problem
Götz Babin-Ebell [EMAIL PROTECTED] writes: And how gets he the connection IP-Address - FQDN ? -He uses DNS. I think you need to reread his message since that's not what he says. If he wants to allow user XYZ presenting certificate C_XYZ to do some things, all he has to do is look in an internal table to map the cert to the allowed tasks. Introducing the FQDN into this is a useless layer of complexity... This is exactly what he's doing but he wants to use the FQDN as the lookup key. If he knows that the FQDN is in the certificate, this is perfectly reasonable. Consider the case of SMTP-relaying. You wish to ensure that only certain hosts can relay through you which requires determining which each client is. In the old days you'd get their IP and do a reverse lookup. If you require clients to have certificates then you can just ignore the IP, get the certificate and make your access decision off the DN. It's extremely convenient to be able to express these decisions in the language of hostnames, so it's convenient to have the FQDN in the DN and use that for your access control decisions. This has the added advantage that you can express expressions, e.g. allow connections from *.example.com. Provided that you can trust the CA to only issue certificates with correct FQDNs in them (which people do, since that's required for SSL security) then this is quite a useful procedure. -Ekr __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Client Authentication Problem
On Wed, 26 Sep 2001 09:43:02 -0700, Michael Sierchio wrote: Don Zick wrote: I have recently started using OpenSSL. (I have found the SSL and TLS book by Eric Rescorla to be invaluable.) I am having a problem with client authentication. After a successful SSL_accept() I have some logic that verifies that the Common Name in the client certificate matches the client's DNS name. This works just fine. However, if the Common Name does not contain the client's DNS name, I would like to check for the client's DNS name in the subjectAltName extension. This is where I'm having a problem. I attempt to check the subjectAltName extension as follows: Why bother binding client certs to a DNS name? In a mutually authenticated SSL connection, IP addresses may not be important. That each party is in possession of the private key and the certs are not revoked should be sufficient. Sufficient for what? I may not want to send my credit card information to anyone who has a Verisign certificate, but I might be willing to send it to someone who has a Verisign certificate for 'www.amazon.com' or has that listed as one of the alternate names. Comparing the name to name you get when you resolve the IP you connected to doesn't seem useful to me. But comparing the name (or alternate name) to the name you expected to connect to makes very good sense. DS __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: 0.9.6b Engine and IBM HTTP Server AXL300
On Wed, Sep 26, 2001 at 06:46:34PM +0100, Richard Grey wrote: Hello, I've got and compiled OpenSSL-engine-0.9.6b on Windows 2000 using nmake -f ns\ntdll.mak. Great. Question is, now what do I do ? I can't find any documentation on what to do next. I'm trying to install and configure a Compaq AXL300 SSL Accelerator Card under Windows NT/2000 using IBM HTTP Server: IBM_HTTP_Server/1.3.6.2 Apache/1.3.7-dev (Win32). I don;t believe that the IBM HTTP server utilizes openSSL for the SSL stack there is a separate IBM provided SSL module which in the Websphere4.0 product suite (Not sure if the IHS 1.3.6.2 is part of this but I doubt it) supports SOME PKCS#11 tokens (only those which have been tested by the developers are supported). Can anybody please help ? -- Richard Grey Client: mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] Phone: +44 (0)1628 584 128 -- * Simple2 Limited is regulated by the Personal Investment Authority. The information in this E-Mail is confidential and may be legally privileged. It may not represent the views of Simple2 Ltd. It is intended solely for the addressees. Access to this E-Mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any unauthorised recipient should advise the sender immediately of the error in transmission. Simple2 Ltd is part of the Scottish Southern Energy Group * -- Steven A. Bade UNIX Network Security Cryptographic Strategy and Development Architecture [EMAIL PROTECTED] T/L 678-4799 (512)-838-4799 -- To convert from Hogsheads to Cubic Feet - Multiply by 8.4219 Two-way communication is necessary to proactively facilitate acceptance and involvement and to get insights about the journey it takes to get where we want this mess is so big and so bad and so tall, we cannot clean it up, there is no way at all (Cat in the Hat) he Hat) __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Client Authentication Problem
Don Zick wrote: Hello Don, I'm not actually using DNS at all. For the application I'm working with the TLS clients and servers must be statically configured with a Fully Qualified Domain Name. I match up the statically configured FQDN for a client with the DNS name from the client's certificate. You are using DNS. On the network layer you only have the IP address. To get the FQDN you need to use DNS. And compared with certificate / private key authentication it is trivial to forge a wrong DNS answer. (At least if you don't use DNSSEC on all your clients and servers...) When an attacker is able to steal a private key, he is also able to poison your DNS... Bye Goetz -- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 S/MIME Cryptographic Signature
Re: Client Authentication Problem
David Schwartz wrote: Sufficient for what? I may not want to send my credit card information to anyone who has a Verisign certificate, but I might be willing to send it to someone who has a Verisign certificate for 'www.amazon.com' or has that listed as one of the alternate names. There's confusion in the PKI realm about what constitutes trust and authority. My assumption is that the certificate issuer does due diligence -- presumably, that's YOU if you are developing an application using client auth. Comparing the name to name you get when you resolve the IP you connected to doesn't seem useful to me. But comparing the name (or alternate name) to the name you expected to connect to makes very good sense. You're talking about connecting to a server via HTTP, which has little if anything to do with SSL and mutual authentication. I maintain that it is far easier to poison a DNS cache than to recover someone else's private key (if reasonably secured). Client certs should bind public keys to identity -- however that is defined by the application. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Client Authentication Problem
On Wed, 26 Sep 2001 15:21:09 -0700, Michael Sierchio wrote: David Schwartz wrote: Sufficient for what? I may not want to send my credit card information to anyone who has a Verisign certificate, but I might be willing to send it to someone who has a Verisign certificate for 'www.amazon.com' or has that listed as one of the alternate names. There's confusion in the PKI realm about what constitutes trust and authority. My assumption is that the certificate issuer does due diligence -- presumably, that's YOU if you are developing an application using client auth. No, the application developer may not be the certificate issuer. The application developer (or whoever configured the application to accept certificates signed by a particular authority) must trust the certificate issuer to at least some extent. That extent could vary from total trust to do anything down to trust only for proof of identity. Comparing the name to name you get when you resolve the IP you connected to doesn't seem useful to me. But comparing the name (or alternate name) to the name you expected to connect to makes very good sense. You're talking about connecting to a server via HTTP, which has little if anything to do with SSL and mutual authentication. I maintain that it is far easier to poison a DNS cache than to recover someone else's private key (if reasonably secured). Huh? A secure HTTP connection does use SSL and can use mutual authentication. Client certs should bind public keys to identity -- however that is defined by the application. And the application can reasonably do that by checking the name in the certificate and comparing it to the name of the thing the application wanted to send data to. (Assuming the certificate issues is trusted at least to provide accurate identities.) DS __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Please help me!
Valery -- This field in a certificate points to where the issuer will make its certificate revocation list available. If you are using OpenSSL or OpenCA (based off of OpenSSL) to issue your certificates you will want to probably put up a web server or LDAP capable directory where you can make your certificate revocation list available; refer to the absolute URL for this list in this extension. You may also want to include an AIA (authorityInformationAccess) extension as well, this can point to a OCSP responder capable of responding with individual certificate statuses. The Microsoft platform implements its revocation handling in a library called cryptnet.dll; this supports all the transports that WinInet supports (http/s,ftp,ldap/s,file). When the CryptoAPI applications that use revocation checking (Outlook can be configured to do this and in Office XP it is the default behavior), cryptnet will attempt to retrieve the CRL specified in this extension and use it for revocation checking. There are also alternate revocation providers available windows that implement additional protocols (OCSP, SCVP, CRL, CRLdp); ValiCert produces one such provider. I hope this helps. Ryan -Original Message- From: Valery [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 26, 2001 1:12 AM To: [EMAIL PROTECTED] Subject: Please help me! Hello! I used the certificate extensions crlDistributionPoints in my openssl.cnf file. And I faced the following problem. What should I indicate in thihs field (crlDistributionPoints)? I need that MS Outlook Express checks if the certificate has been revoked or not when it is on-line? What do I need to do? Yours faithfully, Valery E-mail: [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]
Signing Browser Client Certificates
Hello again: I read the OSPKI book, which pointed me at the sign.sh script which helped quite a bit. I'm wondering if anyone can help me with a few specifics. So far, how I understand a certificate request gets signed is: 1) put the CSR into a file. 2) generate a configuration file that specifies: a) CA information, including which certificate b) the subject DN c) the certificate version (SSL v2, v3) d) any certificate extensions (I'm still hazy on how to specify certificate extensions; also if I need to specify any for a cert that's coing to be a browser client cert, and if so which ones) e) any other information that's required (can someone fill me in on any other essential information for tha config file?) 3) sign the request, a perlish way is my $cert = `\usr\local\bin\openssl ca -in cert.pem`; 4) do whatever post processing (store it in a DB, etc) needs to be done 5) send it back to the user. One more question: can Netscape SPKAC files be converted into other formats? --Christopher __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
