RE: Exportability of software based on OpenSSL libraries
> > In my experience if you just refer to the SSL/TLS spec you're fine. > >Really? Even if you don't specify any algorithms or key lengths in detail? Yeah. We just said RSA key exchange (512 through 2048 bits typical) for symmetric encryption key. For details, see RFC . >Where did you get that from? Maybe I'm out of the loop, but last I checked, > a product with encryption hooks was an encryption product. But there's nothing to fill out. Take the forms at face value, you have nothing to fill out. The old days of NSA experts evaluating every crypto-like thing are gone. It's all Dept of Commerce, and they don't care about crypto with a hole. > Wow, your experiences are totally different from mine. Or maybe I just did > more than I had to. :) /r$ __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Exportability of software based on OpenSSL libraries
> > If you dynamically > > link to OpenSSL, you may have no idea or control over what > > algorithms and > > key lengths you wind up using. This makes the form impossible > > to fill out. > > In my experience if you just refer to the SSL/TLS spec you're fine. Really? Even if you don't specify any algorithms or key lengths in detail? > > If your product includes the OpenSSL libraries, you'd likely > > have to build > > a secure key length limitation into the version of the > > libraries that you > > ship. If your product dynamically links to the OpenSSL > > libraries or permits > > the user to supply his own version, you'd likely have to > > provide reasonable > > secure key length limitations in the application. > If your product doesn't supply crypto, there's no need to apply > for a license. > The old crypto-with-a-hole is dead. In my experiences, if you're > implementing > HTTPS, then just refer to the SSL/TLS spec. If you are implementing a > custom protocol, then you have to fill out all those key parameters. Where did you get that from? Maybe I'm out of the loop, but last I checked, a product with encryption hooks was an encryption product. > > Note that the BXA doesn't care how your code does what it does, > > whether it > > uses OpenSSL or code you wrote yourself or whatever. They just > > care *what* > > your code is capable of doing. > Not true. If you say "I'm just using OpenSSL to implement standard HTTPS" > then you're in lot simpler position than if you grew your own > from scratch. > These folks do understand the landscape out there. Wow, your experiences are totally different from mine. Or maybe I just did more than I had to. DS __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Exportability of software based on OpenSSL libraries
> If you dynamically > link to OpenSSL, you may have no idea or control over what algorithms and > key lengths you wind up using. This makes the form impossible to fill out. In my experience if you just refer to the SSL/TLS spec you're fine. > If your product includes the OpenSSL libraries, you'd likely have to build > a secure key length limitation into the version of the libraries that you > ship. If your product dynamically links to the OpenSSL libraries or permits > the user to supply his own version, you'd likely have to provide reasonable > secure key length limitations in the application. If your product doesn't supply crypto, there's no need to apply for a license. The old crypto-with-a-hole is dead. In my experiences, if you're implementing HTTPS, then just refer to the SSL/TLS spec. If you are implementing a custom protocol, then you have to fill out all those key parameters. > Note that the BXA doesn't care how your code does what it does, whether it > uses OpenSSL or code you wrote yourself or whatever. They just care *what* > your code is capable of doing. Not true. If you say "I'm just using OpenSSL to implement standard HTTPS" then you're in lot simpler position than if you grew your own from scratch. These folks do understand the landscape out there. > Also, you can probably obtain an export > license or license exemption for nearly any combination of algorithms and > key lengths, so you won't have to weaken your export version, just exercise > more control. Agreed. /r$ -- Rich Salz Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Exportability of software based on OpenSSL libraries
> I was told that even though our program is only supporting > limited key lengths, it can not be exported as it is linking to > OpenSSL which has the logic to support larger key lengths and > strong ciphers. This is a misleading thing to say. But in general, it's true that it's very difficult to export a product that can't provide reliable key length limitations. This is because the form you have to fill out requires you to disclose the algorithms and key lengths you will support. If you dynamically link to OpenSSL, you may have no idea or control over what algorithms and key lengths you wind up using. This makes the form impossible to fill out. If your product includes the OpenSSL libraries, you'd likely have to build a secure key length limitation into the version of the libraries that you ship. If your product dynamically links to the OpenSSL libraries or permits the user to supply his own version, you'd likely have to provide reasonable secure key length limitations in the application. Note that the BXA doesn't care how your code does what it does, whether it uses OpenSSL or code you wrote yourself or whatever. They just care *what* your code is capable of doing. Also, you can probably obtain an export license or license exemption for nearly any combination of algorithms and key lengths, so you won't have to weaken your export version, just exercise more control. DS __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Exportability of software based on OpenSSL libraries
>Hi, >I have a question about distribution of software which is based on OpenSSL libraries considering US export regulations. >We are planning to use OpenSSL library to develop a program with functionality similar to that of HTTPS client/server. We >will be linking our code (static or dynamic - any will do) with the OpenSSL libraries. We will not have any encryption code >of our own but only be using APIs/functions from OpenSSL. >We are planning to create two versions of our program - one for US customers and one for export out of US. The exportable >version will only support exportable/weak ciphers. Although it will be linking to the OpenSSL library, at runtime it will >only support key legnths which are allowed under the export control regulations. (i.e. the OpenSSL APIs/functions will be >called with restricted key legnths. I am assuming that we can initialize OpenSSL library at startup or hard-code values in >our code to support only weak ciphers and limit the key length). >Will this satisfy the export requirements? Is an export license or review by the authorities required for this kind of >application? >I was told that even though our program is only supporting limited key lengths, it can not be exported as it is linking to >OpenSSL which has the logic to support larger key lengths and strong ciphers. I believe when a cryptographic product can be used for strong AND weak cryptography, then it is being assessed as a strong crypto product. The fact that an application merely configures it to use weak ciphers is probably not enough. The library itself must reject any attempts to use strong ciphers. This means strong ciphers are excluded during compilation. This brings up a challenging question: how do you tell the crypto library when you call it from the SSL protocol code that a 128-bit RC4 key is not a full strength key but a key with only 40 bits strength where the other 88 bits are reconstructable? The key itself looks the same to the crypto library, and the key length indicates that it is a strong key. You may have to statically link the crypto code to the SSL code to solve this problem. But then no other applications can access the crypto library. >Some more info. We are a US based company and will be exporting out of US. We will not be making any changes to OpenSSL code >and our code can not be open source. >I am sure this must be very common scenario, but haven't found any clear answers. >Thanks >Viral __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Updating a CRL
I'm trying to figure out how to update a CRL without restarting the server. It looks like get_cert_by_subject() wants to see all the successively generated CRLs for a CA. In other words, it wants to see something like 12345.r0, 12345.r1 etc. So I start the server with 12345.r0 in my certificate directory, and then add a new CRL (say 12345.r1). If I then call SSL_CTX_load_verify_locations(), it errors out telling me that it has already loaded 12345.r0. So how can I get the server to load 12345.r1? Note that 12345.r0 should be obsolete, since all of the information it contains should be encapsulated in 12345.r1. Thanks in advance. David __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
new to openssl
Hi, I am just starting out on ssl...could pl. tell me what might be causing the below error, when using s_client to connect to a server, my application also fails during chain verification process... s_client output of the server: Loading 'screen' into random state - done CONNECTED(017C) SSL_connect:before/connect initialization SSL_connect:SSLv2/v3 write client hello A SSL_connect:SSLv3 read server hello A depth=1 /C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certificatio n Services Division/CN=Thawte Server CA/[EMAIL PROTECTED] verify error:num=19:self signed certificate in certificate chain verify return:0 SSL_connect:SSLv3 read server certificate A SSL_connect:SSLv3 read server certificate request A SSL_connect:SSLv3 read server done A SSL_connect:SSLv3 write client certificate A SSL_connect:SSLv3 write client key exchange A SSL_connect:SSLv3 write change cipher spec A SSL_connect:SSLv3 write finished A SSL_connect:SSLv3 flush data SSL3 alert read:fatal:bad certificate SSL_connect:failed in SSLv3 read finished A 1504:error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate:.\s sl\s3_pkt.c:964:SSL alert number 42 1504:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:.\ssl\s23_lib .c:226: thanks, nath __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: copy_extensions = copy?
On Mon, Jun 16, 2003, John Douglass wrote: > I noticed this setting in the openssl.cnf file (as of late) and was > wondering the actual effect of turning this off or on... > > # Extension copying option: use with caution. > # copy_extensions = copy > > It means what it says in the manual page: if its is set then any extensions in the certificate request are copied to the certificate. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
copy_extensions = copy?
I noticed this setting in the openssl.cnf file (as of late) and was wondering the actual effect of turning this off or on... # Extension copying option: use with caution. # copy_extensions = copy Uncommenting means that we can use things like: # Import the email address. # subjectAltName=email:copy or # Copy subject details # issuerAltName=issuer:copy ?? Thanks! - John Douglass, Georgia Tech __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Exportability of software based on OpenSSL libraries
Someone in your company is responsible for trade and/or export regulations. Find out who that is and contact them for guidance. While regulations have become more liberal in some cases, they are always changing so it's good to get up-to-date advice from someone whose job it is to follow the regulations. Check out http://www.bxa.doc.gov/ and then drill down to http://www.bxa.doc.gov/licensing/exportingbasics.htm. The bottom of that document has contact information for export guidance, if you want to consult with them (Bureau of Industry and Security, Department of Commerce). Rick Barry Hewlett Packard Company Secure Web Server Project Team 110 Spit Brook Road OpenVMS System Software Group Nashua, NH 03062 Business Critical Server Group (603) 884-0634 __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Upgrading to the lastest version, what happends with my Apach e-Mod_SSL?
Sorry for my delay in replying. It shouldn't affect SSH as that didn't come with Red Hat 6.2. It's a while since I used 6.2, but at the time I downloaded an RPM from a dutch encryption site (which is now long gone). They used their own security libraries so were independent of openssl. However, your time might be better spent upgrading to a newer version of Linux. - John Airey, BSc (Jt Hons), CNA, RHCE Internet systems support officer, ITCSD, Royal National Institute of the Blind, Bakewell Road, Peterborough PE2 6XU, Tel.: +44 (0) 1733 375299 Fax: +44 (0) 1733 370848 [EMAIL PROTECTED] Evolution isn't true just because the majority of people think it is. > -Original Message- > From: Francisco Javier Martinez Martinez > [mailto:[EMAIL PROTECTED] > Sent: 13 June 2003 14:38 > To: [EMAIL PROTECTED] > Subject: RE: Upgrading to the lastest version, what happends with my > Apach e-Mod_SSL? > > > Thanks for the anwser, > > I was wondering whether with the same scenario (Redhat 6.2) > this upgrade > could affect to other services installed like SSH or not? An > if yes, is > necesary to update them too? > > Thanks and greets. > At 13:42 13/06/2003 +0100, you wrote: > >Yes, but check the mod_ssl website http://www.mod_ssl.org > and ensure you are > >compiling the correct mod_ssl against openssl. Since you > compile mod_ssl > >into apache, you will need to recompile both. > > > >This is why I prefer RPMS! Even if you customise your > version of Apache, you > >only need to build it once and then you can install it on > any number of > >systems. > > > >John > > > - NOTICE: The information contained in this email and any attachments is confidential and may be legally privileged. If you are not the intended recipient you are hereby notified that you must not use, disclose, distribute, copy, print or rely on this email's content. If you are not the intended recipient, please notify the sender immediately and then delete the email and any attachments from your system. RNIB has made strenuous efforts to ensure that emails and any attachments generated by its staff are free from viruses. However, it cannot accept any responsibility for any viruses which are transmitted. We therefore recommend you scan all attachments. Please note that the statements and views expressed in this email and any attachments are those of the author and do not necessarily represent those of RNIB. RNIB Registered Charity Number: 226227 Website: http://www.rnib.org.uk __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: certificate authentication
Marius Cabas wrote: How can i verify from an OpenSSL server application if the client > certificate/private key matches the server certificate/private key? What do you mean,, "match"? The keypair used by the server is not the same keypair used by the client. Do you mean something like "are signed by the same CA" ? /r$ -- Rich Salz, Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Exportability of software based on OpenSSL libraries
Regarding exportability, last I heard export restrictions had been relaxed somewhat for friendly nations. However I'm not American and do not live in the US so not sure. Please, the situation is confusing enough without uninformed speculation. Exporting something which implements HTTP/SSL -- full strength -- is just a matter of paperwork; you can export to all but a half-dozen countries (including, according to information from a couple of weeks ago, "those parts of Afghanistan controlleld by the Taliban" :). Exporting full-strength cryptography for other purposes (e.g., digital signature, arbitrary encryption, etc), is fairly easy to get for about 75% of the world. Some places will be difficult. How do I know? I just finished the process for our full-strength XML firewall and security gateway (see URL below). It does full implementations of XML DSIG and XML Encryption. /r$ -- Rich Salz, Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Exportability of software based on OpenSSL libraries
Are you actually implementing HTTPS, or are you just using SSL over TCP for your own application? We are planning to create two versions of our program This may not be necessary. Is an export license or review by the authorities required for this kind of application? If you use crypto, you need to get a license. If you distribute/develop open source software, you don't need to get a license. In most cases getting a license is "just" a matter of formality. I was told that even though our program is only supporting limited key lengths, > it can not be exported as it is linking to OpenSSL which has the logic to support > larger key lengths and strong ciphers. Whoever told you this does not know what they are talking about, or they simplified the situation so much that their advice is useless. For example, if you are shipping a self-contained system, their advice is irrelevant. If you are shipping statically-linked executable that has been stripped, their advice is probably irrelevant. Get an export lawyer. Get the legal department of your company to find one. /r$ -- Rich Salz, Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Exportability of software based on OpenSSL libraries
Off the home page: OpenSSL is based on the excellent SSLeay library developed by Eric A. Young and Tim J. Hudson. The OpenSSL toolkit is licensed under an Apache-style licence, which basically means that you are free to get and use it for commercial and non-commercial purposes subject to some simple license conditions. Regarding exportability, last I heard export restrictions had been relaxed somewhat for friendly nations. However I'm not American and do not live in the US so not sure. Check with your customs department, it can't be that hard to find out what is required. The only problem you may run into is that many of us outside the US do no accept crippled or limited code. As insecure as it is for you guys it also is for us. There is a reason afterall that the guy(s) who do security call it security. 40-64 bit keys is called "confused clear text." Nothing less than proper 128bit. On Mon, 2003-06-16 at 05:57, [EMAIL PROTECTED] wrote: > Hi, > > I have a question about distribution of software which is based on OpenSSL libraries > considering US export regulations. > > We are planning to use OpenSSL library to develop a program with functionality > similar to that of HTTPS client/server. We will be linking our code (static or > dynamic - any will do) with the OpenSSL libraries. We will not have any encryption > code of our own but only be using APIs/functions from OpenSSL. > > We are planning to create two versions of our program - one for US customers and > one for export out of US. The exportable version will only support exportable/weak > ciphers. Although it will be linking to the OpenSSL library, at runtime it will only > support key legnths which are allowed under the export control regulations. (i.e. > the OpenSSL APIs/functions will be called with restricted key legnths. I am assuming > that we can initialize OpenSSL library at startup or hard-code values in our code to > support only weak ciphers and limit the key length). > > Will this satisfy the export requirements? Is an export license or review by the > authorities required for this kind of application? > > I was told that even though our program is only supporting limited key lengths, it > can not be exported as it is linking to OpenSSL which has the logic to support > larger key lengths and strong ciphers. > > Some more info. We are a US based company and will be exporting out of US. We will > not be making any changes to OpenSSL code and our code can not be open source. > > I am sure this must be very common scenario, but haven't found any clear answers. > > Thanks > Viral > > __ > OpenSSL Project http://www.openssl.org > User Support Mailing List[EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] -- Corey Rogers Junior System Administrator Wamco Technology Group Ltd (Barbados) #3 Mahogany Court, Wildey, St. Michael Phone: (246)437-3154 FAX: (246)228-4319 [F]or those of you who are constantly belittled by your peers for believing that Big Brother is out to get you, be assured, it is. In fact,you are probably not paranoid enough." - editorial, "Today's Technology Can Easily Track Criminals and Ex-offenders", _The_ECHO_ newspaper, Jan. 1998 CONFIDENTIALITY NOTICE: This e-mail message including attachments, if any,is (are) for the intended recipient only (person or entity)and may contain confidential or proprietary information some or all of which may be legally privileged. Any unauthorised review, use, copy, print, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message and do not in any way rely on this e-mail. If you are the intended recipient but do not wish to receive communications through this medium, please so advise the sender immediately. signature.asc Description: This is a digitally signed message part
certificate authentication
How can i verify from an OpenSSL server application if the client certificate/private key matches the server certificate/private key? regards Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail! http://login.mail.lycos.com/r/referral?aid=27005 __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Exportability of software based on OpenSSL libraries
Hi, I have a question about distribution of software which is based on OpenSSL libraries considering US export regulations. We are planning to use OpenSSL library to develop a program with functionality similar to that of HTTPS client/server. We will be linking our code (static or dynamic - any will do) with the OpenSSL libraries. We will not have any encryption code of our own but only be using APIs/functions from OpenSSL. We are planning to create two versions of our program - one for US customers and one for export out of US. The exportable version will only support exportable/weak ciphers. Although it will be linking to the OpenSSL library, at runtime it will only support key legnths which are allowed under the export control regulations. (i.e. the OpenSSL APIs/functions will be called with restricted key legnths. I am assuming that we can initialize OpenSSL library at startup or hard-code values in our code to support only weak ciphers and limit the key length). Will this satisfy the export requirements? Is an export license or review by the authorities required for this kind of application? I was told that even though our program is only supporting limited key lengths, it can not be exported as it is linking to OpenSSL which has the logic to support larger key lengths and strong ciphers. Some more info. We are a US based company and will be exporting out of US. We will not be making any changes to OpenSSL code and our code can not be open source. I am sure this must be very common scenario, but haven't found any clear answers. Thanks Viral __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
