Re: TLS 1.2 Support
Hi Eric, Hi everybody, does openssl already implement TLS 1.2? I do not find anything in the Changelog... I don't find anything about TLS 1.2 (or 1.1) in the Changelog either. Does openssl support TLS 1.2? Since 1.1.0 just started to integrate TLS 1.1, there is surely no TLSv1.2. But if I understand Steve's comment, TLSv1.1 is kind of complete with OpenSSL 1.1.0. OpenSSL CHANGES ___ Changes between 1.0.0 and 1.1.0 [xx XXX ] [...] *) Initial TLSv1.1 support. Since TLSv1.1 is very similar to TLS v1.0 only a few changes are required: Add SSL_OP_NO_TLSv1_1 flag. Add TLSv1_1 methods. Update version checking logic to handle version 1.1. Add explicit IV handling (ported from DTLS code). Add command line options to s_client/s_server. [Steve Henson] [...] Best Regards, Modem Man __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: trusted CA dir in openssl.cnf?
Hi Eric Murray, (are you the buddy also known as the Marlboro Man?) regarding your question, you should know in first place: openssl.cnf and the environment value OPENSSL_CONF are _not_ used by the OpenSSL library by default. With one exception: you compiled your own OpenSSL lib with -D OPENSSL_LOAD_CONF I tried this some weeks before and ran into next problem, then I lost the fun to try out more ... with best regards, Modem Man (aka Sarge) How do you point to a dir (hashed by c_rehash) of trusted CA files (for clients verifying server certs) in openssl.cnf? Is it the 'certs' directive? The comment for certs in the example openssl.cnf says # Where the issued certs are kept and it is in the default_ca stanza which doesn't seem like it would affect clients. Is there a way to specify multiple dirs? I know I can use SSL_CTX_load_verify_locations() to set the location but I want to do it using the conf file so programmers calling openssl don't have to know to call SSL_CTX_load_verify_locations() to get my dir(s) of trusted CA certs. Thanks! Eric __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2245] [PATCH] Add /Zi to VC++ CFLAG in debug configuration (1.0.0 and 0.9.8)
Dr. Stephen Henson wrote: That's most peculiar. I've tested 1.0.0-stable with Visual Studio Express 2008. I did the following simple test: Start openssl.exe Start VS express. Select tools-attach to process. Debug-Break All. I get a warning about deadlocked process but it is otherwise OK. I can set breakpoints and source code is displayed. This worked for debug shared and static builds. The non-debug builds didn't show any source and it said there were no symbols. This is working here, too. But... I have some very different directories for OpenSSL source tree (d:\proj.svn\common\openssl-1.0.0), plus for my project code (d:\proj.svn\Training\ssl1\MrFtp) and finally for the installed OpenSSL binaries (aka '--prefix', here it is: C:\tools\OpenSSL). The crazy thing now comes (please kindly keep patience, the solution is also coming at end of the mail): I built OpenSSL 2 times. The first one, with additional /Zi goes to = C:\TOOLS\OpenSSL, The second one, with normal -Zi goes to = C:\temp\OpenSSL, I tried your debug/attach test - it works even for C:\temp\OpenSSL\bin\openssl.exe (no extra /Zi) Then I changed my local project to use -I C:\temp\OpenSSL\include and linker uses c:\temp\OpenSSL\lib. Expecting to _not_ beeing able to jump into ERR_load_BIO_strings(), I am surprised. It works now! Next, I changed back -I C:\TOOLS\OpenSSL\include and linker uses c:\TOOLS\OpenSSL\lib. This is, where I have my /Zi-extra-built installed. Surprisingly, now _this_ version is not able to be debugged anymore! Linker tells: 1Generating Code... 1Linking... 1libeay32.lib(cryptlib.obj) : warning LNK4099: PDB 'out32.pdb' was not found with 'c:\tools\openssl\lib\libeay32.lib' or at 'd:\proj.svn\Training\ssl1\debug\out32.pdb'; linking object as if no debug info 1libeay32.lib(mem.obj) : warning LNK4099: PDB 'out32.pdb' was not found with 'c:\tools\openssl\lib\libeay32.lib' or at 'd:\proj.svn\Training\ssl1\debug\out32.pdb'; linking object as if no debug info 1libeay32.lib(mem_dbg.obj) : warning LNK4099: PDB 'out32.pdb' was not found with 'c:\tools\openssl\lib\libeay32.lib' or at 'd:\proj.svn\Training\ssl1\debug\out32.pdb'; linking object as if no debug info The files out32.pdb / out32dll.pdb are still laying around in d:\proj.svn\common\openssl-1.0.0. Should this be the reason? wrong location of *.pdb files? I copied them into c:\TOOLS\OpenSSL\lib and my projects d:\proj.svn\Training\ssl1\debug folders. No help - linker is complaining they are not referring to the *right* library: 2Generating Code... 2Linking... 2libeay32.lib(cryptlib.obj) : warning LNK4204: 'd:\proj.svn\Training\ssl1\debug\out32.pdb' is missing debugging information for referencing module; linking object as if no debug info 2libeay32.lib(mem.obj) : warning LNK4204: 'd:\proj.svn\Training\ssl1\debug\out32.pdb' is missing debugging information for referencing module; linking object as if no debug info If I understand this right, without the extra /Zi, the _location_ and the _content_ of out32*.pdb files is very important. To give the final proof, I again built the whole OpenSSL with my default --prefix=c:\TOOLS\OpenSSL, but this time /without/ the extra /Zi. Then again recompiled and started my training project ... now the debugging again works. _Conclusion_: With standard build rules (configure, make, test, install) _without_ a patched '\util\pl\VC-32.pl', VS2005 debugging _is_ working for both process attach and Run/Debug-in-single-Steps. But only if some more prerequisites are kept in mind: * source directory tree (where INSTALL.W32 resides) shall not be cleaned or removed after successfully run of 'make install' * this source directory must contain out32[dll].pdb * out32[dll].pdb must be created together with the same make configure make install call, which created your [prefix]\include and [prefix]\lib directories and content * your C project needs to include exactly the mentioned [prefix]\include and [prefix]\lib components, because its path seems to be encoded in out32[dll].pdb and vice versa. _Conclusion_ II: With standard build rules (configure, make, test, install) _plus_ a patched '\util\pl\VC-32.pl' (added /Zi), VS2005 debugging _is_ working for both process attach and Run/Debug-in-single-Steps, without some of the prerequisites mentioned above. The PDB files are neither in the openssl directory nor in the [prefix] directory. But debuging works. puh, long tests, long mail, short conclusions. Hope this helps for somebody, Modem Man __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2245] [PATCH] Add /Zi to VC++ CFLAG in debug configuration (1.0.0 and 0.9.8)
Dr. Stephen Henson schrieb: On Wed, Apr 28, 2010, Modem Man wrote Stephen Henson via RT schrieb: [mounir.idra...@idrix.net - Mon Apr 26 20:18:42 2010]: Hi, This patch adds the /Zi switch to CFLAG in the debug configuration in order to permit stepping inside OpenSSL code during debug sessions. It applied to the latest snapshots of 1.0.0 and 0.9.8 source trees. Note that 1.0.0 makes the Win32 build system a bit saner: it uses some command line options from the Configure line (like other targets). The debug-VC-WIN32 target already includes -Zi (same as /Zi) so that change is unnecessary. Dear Stephen, I'm using VS2005 and built my 1.0.0 with 'debug-VC-WIN32', and there was no /Zi at all. Mounir gave me the hint and I modified my .\util\pl\VC-32.pl very similiar to his patch. AFTER doing this, it worked for me. BEFORE doing this, I was not able to jump into the code. Not even into the x86 asm representation, which is shown by VS in cases, the source can't be found. So in my opinion, it is indeed required patch for 1.0.0 With great respect about your work, Modem Man That's strange. I've just tried this in the latest 1.0.0-stable tree: perl Configure debug-VC-WIN32 ms\do_nasm and in ms\ntdll.mak is this: CFLAG= /MDd /Od -DDEBUG -D_DEBUG -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -Zi -nologo ... Note the -Zi and not /Zi. Does that not happen on your system? wait a minute... ms\nt.mak (and compareable ntdll.mak) with original .pl file: CFLAG= /MTd /Od -DDEBUG -D_DEBUG -DOPENSSL_THREADS -DDSO_WIN32 -W3 -WX -Gs0 -GF -Gy -Zi -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE /Fdout32 -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_DYNAMIC_ENGINE with /Zi enriched .pl file: CFLAG= /MTd /Zi /Od -DDEBUG -D_DEBUG -DOPENSSL_THREADS -DDSO_WIN32 -W3 -WX -Gs0 -GF -Gy -Zi -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE /Fdout32 -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_DYNAMIC_ENGINE The only difference is just the additional /Zi, plus the fact that this version works for IDE debugging. Hmm, it looks like -Zi doesn't work at all or doesn't work at that particular place? Crazy... What shall I test next? with best regards, Modem Man
Re: [openssl.org #2245] [PATCH] Add /Zi to VC++ CFLAG in debug configuration (1.0.0 and 0.9.8)
Stephen Henson via RT schrieb: [mounir.idra...@idrix.net - Mon Apr 26 20:18:42 2010]: Hi, This patch adds the /Zi switch to CFLAG in the debug configuration in order to permit stepping inside OpenSSL code during debug sessions. It applied to the latest snapshots of 1.0.0 and 0.9.8 source trees. Note that 1.0.0 makes the Win32 build system a bit saner: it uses some command line options from the Configure line (like other targets). The debug-VC-WIN32 target already includes -Zi (same as /Zi) so that change is unnecessary. Dear Stephen, I'm using VS2005 and built my 1.0.0 with 'debug-VC-WIN32', and there was no /Zi at all. Mounir gave me the hint and I modified my .\util\pl\VC-32.pl very similiar to his patch. AFTER doing this, it worked for me. BEFORE doing this, I was not able to jump into the code. Not even into the x86 asm representation, which is shown by VS in cases, the source can't be found. So in my opinion, it is indeed required patch for 1.0.0 With great respect about your work, Modem Man
Re: Win32 OPENSSL_USE_APPLINK usage
Andy Polyakov schrieb: I actually ended up solving it by removing all uses of BIO_new_fp() in favor of my own custom BIO that I just finished writing earlier this week. Why not BIO_new_file? Yeah, I discovered while analyzing the code that using BIO_new_file() rather than BIO_new_fp() would disengage applink, however that was not an option for me because BIO_new_file() can't open a file whose name contains non-ANSI Unicode characters on Windows. I have to open the file myself using _wfopen(). There was suggestion to fall back to wfopen from a vmware engineer a while ago, but he couldn't provide patch (not that it would be very complex) and it was not followed up. Idea must have been something similar to just committed http://cvs.openssl.org/chngview?cn=19610. why not adding the following to BIO_new_file()? - BIO interface still uses char * (meaning latin ASCII 0x20..0x7F) - BIO implementation calls UTF8_to_UCS16() on all platforms supporting wfopen or _wfopen - BIO implementation then calls wfopen / _wfopen with this UCS16 value (sometimes known as WCHAR*) - For Win32 and Win32_WinCE the conversion can be done with FormatMessage() API. It's allways available. ... just my 5 cents. The Modem Man __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: question regarding crypto\bio\bio_lib.c and num_read
I think, it could be a bug, not yet noted by others because never used num_read. Regards, M.M. Ray Satiro schrieb: Both BIO_write() and BIO_puts() increment num_write on success. But BIO_gets() by all appearances does not increment num_read, only BIO_read() does. I don't see why that omission in BIO_gets() would be intentional. Any thoughts? Thanks, Jay __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
