Re: scripting s_server
If not, you should be able to script it using expect. The expect tool can be used do script execution of any text based program. autoexpect -p -f start_s_server openssl s_server -key [type password when prompted] [make s_server exit normally, NOT control-c. kill from another window is fine] The above should provide a start_s_server script that can be used to start s_server with the encrypted key. -- Henrik Nordstrom MARA Systems Patrick Li wrote: > Hi Lutz, > > I think I will just remove the encryption on the private key file using the > command suggest by Henrik. > > openssl rsa -in key.pem -out key_unprotected.pem > > I wrote a SSL client program and want to use s_server for testing. That'll > help me to automate the testing without typing in the passphrase > interactively. > > Thanks! > Patrick __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Need of client session reuse advice
Hi, I am looking into how to best add client session reuse to Squid when acting as a SSL client. (yes, Squid does SSL these days) The playfield: * A single process * Having a large amount of SSL connections to a large amount of different places (servers), and some prefedined places (peers) * Each peer may consist of multiple servers (each has a unique IP:port), optionally with session sharing. * Using non-blocking I/O. The primary goal is to get session reuse for SSL connections to peers, which should not be too hard it seems. General session reuse on any initiated SSL connection is also interesting, but mostly as an exercise for the brain however as there is not and should not be many users who need a http->https gateway these days. This should be somewhat like what a browser needs to support in session reuse for a user browsing several https sites at the same time with the same browser instance. I think I have got the SSL_get1_sess and SSL_set_session picture, and have some kind of idea of how to use this using your own cache structure. Still needs to look into how to correctly manage time-to-live etc. But what confuses me is the fact that there is a SSL_SESS_CACHE_CLIENT session cache mode (SSL_set_session_cache_mode). Can this cache mode be used to make life easier somehow? I understand it will cache client sessions, but how to access the cached sessions? And how to find the correct set of cached sessions among all different sessions used in this SSL_CTX if the same SSL_CTX is used for connecting to different SSL servers? I was thinking that maybe I can use SSL_SESS_CACHE_CLIENT in a manner like this: * Set up application data fields to identify which server connection the session belongs to (the keys needed to later look up the session etc, i.e. ip:port). * Register a SSL_CTX_sess_set_new_cb to index the cached sessions using the data set in 1. * Use this custom index to find a correct session to reuse. * And the proper application data free calbacks to automatically deregister the sessions from the index when deleted. Some other questions regarding SSL sessions: * Should the SSL session be reused for multiple concurrent connections to the same server where possible, or only one connection at a time? Regards Henrik -- Henrik Nordstrom <[EMAIL PROTECTED]> MARA Systems AB __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Signing a binary file
mån 2003-08-04 klockan 18.54 skrev Danny Joseph: > I am new in the openssl world so my questions migth be basic. > I have a binary code file that I have to sign (using a private key and one > or more certificat). > It has to be PKCS#7(SHA1 with RSA encryption) DER encoded Signed Data. > So : > 1- I have to create a PKCS#7 data message from my binary file. > 2- Sign this last PKCS#7 file -> In my signed data, there will be > one (or more) certificats along with their Signing Info. I need to put a > signing time as well. PKCS7_encrypt() & PKCS7_sign() maybe? I do not think the required operations is available in the openssl tool for your purpose. Some programming will probably be needed to use OpenSSL in this manner. Note: The OpenSSL pkcs7 functions is primarily designed for SSL related operations (i.e. CRL lists) and as such is not a complete PKCS #7 implementation from what I can tell. It is fully possible what you are trying to accomplish is beyond the capabilities of the OpenSSL PKCS #7 functions. For example the documentation to PKCS7_sign() says (under BUGS) that only a single signer certificate is supported by the implementation. Regards Henrik -- Henrik Nordstrom <[EMAIL PROTECTED]> MARA Systems AB __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Need of client session reuse advice
mån 2003-08-04 klockan 19.24 skrev Geoff Thorpe: > Yes. There's normally no reason to cache more than one (client) session > for any given server, and usually the best strategy is to cache the most > recent one (or more correctly, the one that expires last). Question: how > are you handling client-authentication if it arises? There is a can of > worms waiting for you here, perhaps you're already aware of it? There is limited support for "client" authentication here. Squid only supports a single client certificate per type of outgoing SSL connection when initiating SSL connections. Note that this use of SSL is not related to proxying of SSL requests from the end-users. Only when you set up Squid to SSL encrypt connections Squid make. Examples of uses are: * Encryption of connection between two Squid servers * Encryption between a Squid running in accelerator mode and the accelerated web server (to the end-user Squid is the endpoint). and the kind of moot operation these days: * Gatewaying to https:// for clients who do not support SSL > If squid > is proxying on behalf of multiple clients, then you risk introducing some > weird security issues. For better or worse, HTTPS is often used in a > rather layer-violating way. Eg. if web-server logic attaches/indexes > state based on SSL/TLS session details, then if you (as squid) reuse that > session for a different client, you risk having that client be > interpreted by the server as the client who happened to be proxying when > the session was negotiated. Ugh,, I think I get the problem. Some servers connect HTTP state information to the SSL state. This problem we have seen in HTTP alone already (servers connecting HTTP state information to TCP connections) and I imagine it can get a lot worse with SSL sessions.. But fortunately I do not think this will be much of a problem in the intended scopes of use. > https-https proxying is a different kettle of fish to > http-https proxying. How are you doing this anyway? By proxying the https:// request, not the SSL. Perhaps best described as https->https gatewaying if the client talks SSL/https to Squid. > Do you specify a new CA cert to the clients that, once accepted, > allows you to do dynamic MITM SSL/TLS proxying by faking server > certificates according to the CONNECT string? Or something else? Something else. The current implementation is mostly for accelerators and simply implement a standard SSL server with it's own certificate. It does NOT intercept CONNECT requests ot hijacked port 443 request, it just accepts whatever requests the client sends to a SSL enabled port to Squid, acting as a web server to the client. The main difference from a normal web server is that we do not have any original data of our own, but rely on http/https to fetch the data (there is also a few other differences at the HTTP layer originating from Squid being a caching proxy). > There's no harm reusing it for multiple concurrent connections - this is > the most common application (a browser negotiating a session for an html > page will then typically fire off various concurrent session resumes to > go back and pick up all the image files too). As I say, the question is > more how you identify/index SSL sessions in a satisfactory way (and with > suitable granularity) so that you get the maximum performance pay-off > from resumes, but without creating mistaken identities for any server > that matches up browser-clients to corresponding SSL/TLS state. Thanks. The SSL session concept is much clearer to me now, and you have highlighted a couple of DONT DO THIS issues we need to have clearly documented together with a few tuning knobs to tune when/how session reuse is allowed. I think I will limit myself to session reuse for known peers for the time being and leaving https:// proxying/gatewaying aside. This is the most interesting area for us at the moment, and gives a very controlled play field with easy mechanisms of tuning the desired behavior. Now back to questions: All examples I have found gets the session just before SSL_shutdown(). Would not a more appropriate place for a multi-connection application like Squid be just after a successful SSL_connect()? The SSL session can be immediately reused, right? Should not be any need to wait for a complete SSL connection to finish until shutdown before reusing the session from what I can understand from this discussion. Regards Henrik -- Henrik Nordstrom <[EMAIL PROTECTED]> MARA Systems AB __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL algorithm and Java
tor 2003-08-07 klockan 13.06 skrev Davide De Benedictis: > Using the command tool "genrsa" how can I specify to store the > private key in PKCS#8 or PKCS#12 standard format? You could use something like the following I suppose: openssl genrsa 1024 | openssl pkcs8 -topk8 This uses genrsa to generate a RSA key and then encrypts it as a PKCS#8 encrypted key. Regards Henrik -- Henrik Nordstrom <[EMAIL PROTECTED]> MARA Systems AB __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: MD5 Decryption question
On Tue, 12 Aug 2003, Jason Berger wrote: > I was able to encrypt a string using MD5. How do I decrypt it back into > Meaningful data? MD5 is a hash, not a crypto. You can't turn a hash back into the original, but by exchaning a hash like MD5 it can be verified that two parties have access to the original or that two originals are identical without exchaning the original. For this reason you find MD5 hashes commonly in reference to files which may be downloaded allowing you to verify that the file downloaded is the correct file and not corrupted, and MD5 is also found as part of various secure authentication schemes who never exchange the password but rather just a proof that the correct password is known. Regards Henrik __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: passphrase
tis 2003-08-05 klockan 15.12 skrev [EMAIL PROTECTED]: > openssl rsautl -decrypt -inkey private/cakey.pem -in crypt.bin -out > out.txt > > after this console prompt me for passphrase. I need write it as > parameter. Does not seem to be any command line parameters for specifying key passphrase to rsautl. The rsa command has the ability to read passphrase from a file, but rsautl does not seem to have such option. One way around this limitation is to script the execution of the command using expect. Another (not recommended) is to temporarily decrypt the key with the rsa command. This is not recommended as it causes both the passphrase and the decrypted key to be temporarily stored in files. Regards Henrik -- Henrik Nordstrom <[EMAIL PROTECTED]> MARA Systems AB __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Segmentation Fault in BN_bn2bin...
On Mon, 11 Aug 2003, Mateus wrote: > I'm trying to use the function BN_bn2bin to convert a big number and I > had a segmentation fault inside of it. Is the to area allocated and big enough to fit the number? Is the BIGNUM ok? Try printing it with BN_print_fp. Have you perhaps stomped on some other memory prior to the call? Try valgrind or another memory debugger. Regards Henrik __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Why SSL_write() fails....HELP REQUIRED!!!!!!!!!!!!
On Sun, 10 Aug 2003, Sunil Ashok Rashinkar wrote: > Hi Henrik Nordstrom, There is more people than only me in this list.. I am probably not at all the most qualified for this question. > SSL_write(sslConnection, data + bytesTransmitted, bytesToSend); > This SSL_write fucntion fails and returns 5 as error code. > Error code is retrieved by --> nError = SSL_get_error(sslConnection, > bytesSent); > Error string is retrieved by --> ERR_error_string(nError, str); > Erro string which i get is --> error:0005::lib(0) :func(0) : bad asn1 > object header I am guessing wildly here, but perhaps some non-SSL data was received from the other end of the connection? Or maybe the error occured earlier during SSL_connect/accept? Have you tried OpenSSL PROG FAQ 5: I've called 'some function' and it fails, why? http://www.openssl.org/support/faq.html#PROG5>. Maybe this gives a better description of the error(s) which may have occured. > I also read your friends comments regarding solution of this problem, which > said... > > char buf[20]; > > RAND_seed(&buf,sizeof buf) ; > He did the above change in the code and got it working. No idea.. if it was shortage of randomness you should get another error I think. At least I did when I was short of randomness/entropy in one of my applications. In any case the above two lines is a terribly bad randomness seeding method giving a false sense of randomness entropy information to OpenSSL, quite likely degrading the cryptographic security of OpenSSL considerably. If you have a windows application then you should probably be using RAND_window() from the main event loop. I am not a Windows programmer so I am of limited help on how to do this. The platforms I develop on all have /dev/urandom which makes life with randomness requirements considerably easier. Regards Henrik __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL denial of service
On Tue, 19 Aug 2003, Neil Humphreys wrote: > Lee, > Yes I am worried about tcp syn attacks Most TCP implementations handles SYN attacks nicely these days given the opportunity by correct kernel tuning.. you should only need to worry about connection attacks where a full SYN handshake have taken place and the sender is thus verified to exists (or at least to be in the path..) > AND bogus "time wasting" ssl negotiations - basically anything malicious > that can happen to a "naked" listening socket. This you can and should implement in your user-space application if desired. Not a easy task however. Requires you to keep some statistics on operations and errors, and start rejecting clients you consider abnormal in behaviour. To help in this you can probably rely on session reuse to identify "nice" clients, to avoid having already verified users blocked or denied if someone attacks you with a DoS purpose. I think you can hook into the OpenSSL negotiation before a new session is initiated but it is not something I have done.. Regards Henrik __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: newbie question
On Thu, 28 Aug 2003 [EMAIL PROTECTED] wrote: > Is this an SSL, or an Apache directive, if so what directive. I've played > around with "Redirect" but to no avail. And I've tried SSLRequireSSL also > to no avail. Apache. Create a virtual server for the HTTP port, and use a Redirect rule in that server configuration section. For more details see the Apache configuration guides. Regards Henrik __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Apache/IE and OpenSSL: I/O error, 5 bytes expected?
On Tue, 9 Sep 2003, Dann Daggett wrote: > Well, I don't know actually, but the fact that IE does in fact do the > redirect when you go to port 80 and not when you go to 443, and, the fact > that the web server never even records the GET / in it's logs, to me > indicates it's not getting far enough to even send the index.html page back, > right? Try using ssldump to inspect the traffic taking place ssldump -k /path/to/private_key.pem -d port 443 quite amazing little tool and will tell you a lot about the SSL operations of your server. Regards Henrik __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Apache/IE and OpenSSL: I/O error, 5 bytes expected?
On Tue, 9 Sep 2003, Dann Daggett wrote: > resume [32]= > af ea 93 ad 17 8d d2 e7 9a 8d 7f a7 8f a0 8b 17 > 63 93 33 68 0d 43 99 94 b6 c9 dd e2 f8 17 3d 6f > NULL > 1 2 0.0056 (0.0043) S>C Handshake > ServerHello > Version 3.1 > session_id[32]= > af ea 93 ad 17 8d d2 e7 9a 8d 7f a7 8f a0 8b 17 > 63 93 33 68 0d 43 99 94 b6 c9 dd e2 f8 17 3d 6f Looks like a resumed session.. please note that ssldump will get a bit confused unless it saw the initial handshake where the session was established. ssldump traces are best collected by first closing the browser or flushing the server session cache and works absoulutely best with session cache disabled (server setting). > cipherSuite TLS_RSA_WITH_RC4_128_MD5 > compressionMethod NULL > 1 3 0.0056 (0.) S>C ChangeCipherSpec > 1 4 0.0056 (0.) S>C Handshake > 1 5 0.0068 (0.0011) C>S ChangeCipherSpec > 1 6 0.0068 (0.) C>S Handshake > 10.0085 (0.0017) C>S TCP FIN > 10.0088 (0.0002) S>C TCP FIN Loooks very short to me.. client immediately closes the connection after the SSL connection is established. Total sessoin time (from SYN to FIN) only a fraction of a section (0.0088 seconds). Probably a broken client.. Try forcing the use of another ciphersuite in case the problem is the implementation of this specific cipher. Regards Henrik __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Triple DES ECB - just with key - no iv no salt
On Tue, 16 Sep 2003, Richard Levitte - VMS Whacker wrote: > In message <[EMAIL PROTECTED]> on Tue, 16 Sep 2003 13:56:40 +0100, Robert Hogan > <[EMAIL PROTECTED]> said: > > robert.d.hogan> I only want to use the key - no salt and no iv. As far > robert.d.hogan> as I understand it, ECB does not require an > robert.d.hogan> IV. However, when I try the first part of the > robert.d.hogan> operation: > > Do "openssl enc -h" and observe the difference between -k and -K. Now > look at the command you cited above. At this point, your brain should > go *ding* *ding* *ding* :-). ??? Isn't it just the case that the enc command insist on having an iv specified even if not actually used by the des-ecb cipher? And to run des-ecb with a specified key (not password) one must supply a dummy iv just to make the enc command happy with it's arguments. Regards Henrik __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Cert chain confusion
On Tue, 16 Sep 2003, Dann Daggett wrote: > Now, when an outsider connects to my secure server, my server > should present that client with a certificate right? Which > certificate does it present? The server's cert, or the CA's? The servers. > Or does it need to present both? It does not hurt to present both, but is not strictly required if the client already trusts your CA. If the certificate is issues by a second level CA and the client trusts the higher level CA who issued the certificate for the second level CA then you must present the CA chain or else the client will not be able to verify the certificate as there is no direct chain of trust from the certificate to the trusted root CA. > I've seen references to > the practice of concatenating the two together and I now > assume this is what might be referred to as a "chain file"? Yes. > But I'm not clear on "how" to concat the two or what in > what order? Is it as simple as > "cat x1.pem cacert.pem > chainfile.crt" > And if so, should it be only the ---BEGIN CERT -- to ---END > CERT--- data, not all of the rest of the text, or can it > include the human readable text as well? As long as it contains the ---BEGIN CERT... blocks openssl applications with support for loading certificate chain files should be be fine. Any content outside these blocks are ignored by OpenSSL. See the documentation for the server application you are using in how certificate chains should be presented to the application. If you are writing your own application then you need to load the certificate chain in the application. There is at least two different methods a) Prepare the chain in the certificate file, and load it when loading the certificate: SSL_CTX_use_certificate_chain_file b) Set up trust to the CAs who issued your certificate before loading the certificate SSL_CTX_load_verify_locations Several other variants are possible. > Also, what's the difference between the /certs and the /newcerts > directories? Is the /certs where I place the certs that I trust > and the /newcerts only stores the certs I've issued, but don't > need to trust them explicitly (since I trust the issuer)? Not really relevant to running servers.. these are just directories used by the CA.pl script and the demoCA configuration. The certs directory is probably meant to contain already issued and delivered certificates allowing you to keep track of which certificates have been delivered to their use and which are newly issued certificates. The directory is not actually used from what I can tell. Regards Henrik __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Cert chain confusion
On Tue, 16 Sep 2003, Dann Daggett wrote: > I understand. Are there options on how the chain is presented? > In particular, is it always presented as a single (combined) > response to the client, or can/does the client make a second > request for the next cert up the chain if it finds it does not > yet trust the last cert presented? It is always presented chained to the certificate of the server, part of the server hello packet. > So I take it the simple "cat" command would do to create the > chain file, right? Yes > I suppose that means the application may or may not require > the certs in the chain file to be in any particular order, > and, one application (i.e. Apache) might even require the > file constructed differently than another app (say Sendmail)? If they want a certificate chain then they will most likely all use the same format. However, not all applications know to load certificate chains. All should know to load a directory or file of trusted CA certificates however, and this should also make OpenSSL build the certificate chain where needed. > That's interesting. So it sounds as though each app must be told > where the certs are and it's NOT something that the OpenSSL lib > inherhently knows? Depends. OpenSSL also have default directories where it looks for CA certificates if the application asks it to use the default CA certificates in addition to any CA certificates provided by the application when verifying the validity of certificates. The application however must tell which certificate and key the application wants to use. > But what about the references I've read that require the > creation of hashed links to the individual certs in a directory? > Who, and/or what, uses that data then? Is that application > dependent as well? Up to the application if it is application dependent or not. OpenSSL can read CA certificates in three manners a) Hashed directory b) Linear file c) Part of certificate chain 'a' and 'b' can exists both as 'default directories' and as application provided. If the application does not say anything no CA certificates is loaded. Maybe it also has built-in CA certificates, I do not know. How it determines the 'default directories' to use I do not know, but there is a SSL_CTX_set_default_verify_paths() call which supposedly sets them up. Always safest to have the application specify the location of trusted CA certificates. Regards Henrik __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Certificate, encoding and signing questions.
On Wed, 17 Sep 2003, Frank wrote: > Encoding - Now from some testing I did with PKCS7 structures before if > you DER encode instead of PEM encode the data it appears to be much > smaller. Is that correct? >From what I have understood PEM is simply BASE64 encoded DER plus headers which clearly indicates what kind of data is encoded, at least as long as you are talking unencrypted entries. So yes DER is more compact than PEM, however PEM is far more suitable for exchange over different mediums such as email etc and generally easier to work with as a quick human inspection immediately tells what kind of data it is about. Regards Henrik __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Dodgy "Microsoft fix" emails
On Mon, 22 Sep 2003, Wayne Rasmussen wrote: > Is there some legal responsibility of mailing lists owner to prevent this? I have not received a single of these via the OpenSSL mailinglist server. I do receive tons of them from other sources however. Why is this discussion at all on this list? Is anyone actually receiving these via the mailinglist? (see the mail headers) Regards Henrik __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
