www.openssl.org down on 2010-05-01?
Hi, is www.openssl.org down today? Or is it just unreachable from Germany? ___ C:\temptelnet www.openssl.org 80 Verbindungsaufbau zu www.openssl.org...Es konnte keine Verbindung mit dem Host hergestellt werden, auf Port 80: Verbinden fehlgeschlagen C:\temptracert www.openssl.org Routenverfolgung zu master.openssl.org [195.30.6.166] über maximal 30 Abschnitte: 11 ms1 ms1 ms router.home [192.168.0.189] 2 1 ms1 ms1 ms fritz.fon.box [192.168.178.1] 344 ms45 ms45 ms 217.0.116.240 448 ms47 ms46 ms 217.237.155.182 552 ms48 ms49 ms f-ee4-i.F.DE.NET.DTAG.DE [62.154.14.230] 651 ms50 ms51 ms 217.243.216.74 757 ms58 ms58 ms MUC-1-eth000.de.lambdanet.net [217.71.96.166] 859 ms58 ms58 ms Cisco-M-XXXI-Te1-5.Space.Net [217.71.99.30] 958 ms58 ms58 ms Cisco-M-XVI-Te1-1-v20.space.net [195.30.3.25] 1058 ms58 ms57 ms Cisco-M-Vlan11.space.net [193.149.44.126] 11 *** Zeitüberschreitung der Anforderung. 12 *** Zeitüberschreitung der Anforderung. 13 *** Zeitüberschreitung der Anforderung. ___ greetings, Modem Man __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: www.openssl.org down on 2010-05-01?
It's now reachable again, thank to whom it belongs... MM Modem Man schrieb: Hi, is www.openssl.org down today? Or is it just unreachable from Germany? ___ C:\temptelnet www.openssl.org 80 Verbindungsaufbau zu www.openssl.org...Es konnte keine Verbindung mit dem Host hergestellt werden, auf Port 80: Verbinden fehlgeschlagen C:\temptracert www.openssl.org Routenverfolgung zu master.openssl.org [195.30.6.166] über maximal 30 Abschnitte: 11 ms1 ms1 ms router.home [192.168.0.189] 2 1 ms1 ms1 ms fritz.fon.box [192.168.178.1] 344 ms45 ms45 ms 217.0.116.240 448 ms47 ms46 ms 217.237.155.182 552 ms48 ms49 ms f-ee4-i.F.DE.NET.DTAG.DE [62.154.14.230] 651 ms50 ms51 ms 217.243.216.74 757 ms58 ms58 ms MUC-1-eth000.de.lambdanet.net [217.71.96.166] 859 ms58 ms58 ms Cisco-M-XXXI-Te1-5.Space.Net [217.71.99.30] 958 ms58 ms58 ms Cisco-M-XVI-Te1-1-v20.space.net [195.30.3.25] 1058 ms58 ms57 ms Cisco-M-Vlan11.space.net [193.149.44.126] 11 *** Zeitüberschreitung der Anforderung. 12 *** Zeitüberschreitung der Anforderung. 13 *** Zeitüberschreitung der Anforderung. ___ greetings, Modem Man __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Question regarding opening the OpenSSL source code in visual studio
Moshe, Kfir schrieb: Hey I would like to modify the source code of some functions in OpenSSL Since I’m working under Windows and have Visual Studio installed, the easiest way to do so will be by creating a visual studio project with the source code Has anyone ever did something like that, is there by a chance a prepared visual studio project already? I tried it and stopped after ~4 hours. You have to read the ./Makefile which comes out of perl Configure no-asm debug-VC-WIN32 very carefully. Take pen paper. Next, split makefile into modules with same -D and -I settings. Start new VS project solution, consisting of multiple static libraries 8you guessed it: one for each plit module) next, read ms\ssleay32.def and ms\libeay32.def again pen paper, find out, what modules go to ssleay and what to libeay Add 2 DLLs to your project, ssleay32 libeay32 select the appropriate LIBs in project depends on... I think this could last a day or two... have fun, Modem Man
Re: BIO_do_handshake() little help wanted
Dear Stephen and dear all,
regarding Stephen's question below:
On Sat, Apr 24, 2010, Modem Man wrote:
Dear all,
I'm fiddling since two days with BIO_do_handshake(), and always have no
luck.
I'm afraid, it's time to cry for help now.
*Short description:*
After BIO_do_handshake() always returns -1, I always get the message:
/error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher/
from my error printing loop, which is:
while( (code=ERR_get_error_line_data( file, line, data, flags ) ) !=
0 ) {
ERR_error_string_n( code, errX, sizeof(errX) );
syslog( LOG_ERROR, "! %s", errX );
};
*Detailed description:*
The code until the BIO_do_handshake() doing as follows:
1) building a BIO chain, consisting of an accept_socket BIO and a buffer
BIO.
2) accept / pop as usually
3) BIO_gets / BIO_puts, all working fine in non-SSL mode
please note: it is a FTP Server, completely written in OpenSSL
BIO_ and working fine since 2 weeks - until I try to add SSL to my
BIO chain
when we arrive here, it is the 1st command from the sftp client:
4) if seen "AUTH TLS" or "AUTH SSL", I do answering:
"234 AUTH command ok; starting SSL connection.\r\n",
this sets the client into SSL mode, too.
Next, I do inserting a SSL BIO by the following sequence:
(stripped error-check here, but can say, all functions returning ok
so far)
SSL_CTX * ctx;
SSL * ssl;
BIO * sslBIO, *bSock;
ctx = SSL_CTX_new( SSLv23_method() );
SSL_CTX_set_options( ctx, (SSL_OP_NO_SSLv2 | SSL_OP_ALL) );
SSL_CTX_set_mode( ctx, SSL_MODE_AUTO_RETRY );
SSL_CTX_set_cipher_list( ctx, "ALL:DEFAULT:LOW" ); /* also not
working: "ALL:!ADH:!LOW:!EXP:!MD5" */
SSL_CTX_set_default_verify_paths( ctx );
// CAFILE is /debug/servercert.pem
// CAPATH is ./debug path itself, there is also serverkey.pem
SSL_CTX_load_verify_locations( ctx, CAFILE, CAPATH ) );
SSL_CTX_set_verify( ctx, SSL_VERIFY_PEER, verify_cert_callback_foo );
SSL_CTX_set_verify_depth( ctx, VERIFY_DEPTH + 1 );
sslBIO = BIO_new_ssl( ctx, 0 /*server*/ );
BIO_get_ssl(sslBIO, ssl);
SSL_set_mode(ssl, SSL_MODE_AUTO_RETRY);
bBuff = myContext-bio; /* this is the bio I'm already using:
BUFFER+ACCEPT_SOCKET */
bSock = BIO_pop( bBuff ); /* get the raw socket-bio */
BIO_set_callback( sslBIO, BIO_debug_callback_foo );
/* reassemble the chain, now with SSL in the middle: */
myContext-bio = BIO_push( bBuff, BIO_push( sslBIO, bSock ) );
BIO_do_handshake( sslBIO );
!Bang! here I die
Need to say: Windows XP pro SP3, Client is TotalCommander 7.02 with
built in sftp via OpenSSL
Any hint? Help? Suggestion?
Any knowledge of Bug in Totalcommander?
Any Idea of another cost-free sftp client, I can try?
I would appreciate EVERYTHING that brings me a step further...
Have you included OpenSSL_add_all_algorithms() and/or SSL_library_init()?
Yes, I have. Just missed to write it down here, since it is already in
main(). Sorry.
My_InitCryptoSeed();
ERR_load_BIO_strings();
ERR_load_crypto_strings();
SSL_library_init();
SSL_load_error_strings();
OpenSSL_add_all_algorithms();
How could I see, which ciphers the 'other side' is offending? May
be, you can give me one more hint? I thought, it could it be a good
idea to temporarily modify may server, so he immediately jumps into the
"AUTH TLS" handler. So, next, I tested with command
openssl s_client -connect localhost:21
and got:
Loading 'screen' into random state - done
CONNECTED(0720)
5756:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert
handshake failure:.\ssl\s23_clnt.c:658:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 210 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
This looks, is if my server _failed_ to load
SSL_CTX_load_verify_locations( ctx, CAFILE, CAPATH ), right?
I have:
#define CAFILE
"d:\\proj.svn\\common\\openssl-1.0.0\\_MyCerts\\servercert.pem"
#define CAPATH "d:\\proj.svn\\common\\openssl-1.0.0\\_MyCerts"
and there is almost everything *.pem stuff laying around.
When using already compiled openssl.exe, the openssl.cnf file
is loaded from
d:\proj.svn\common\openssl-1.0.0\ssl\openssl.cnf,
so I modified there:
HOME = d:\proj.svn\common\openssl-1.0.0\_MyCerts
[ CA_default ]
dir = d:\proj.svn\common\openssl-1.0.0\_MyCerts # Where
everything is kept
But I do not know, if my server.exe also loads from there...
I also don't know, if my pem files are okay, since I'm pretty new in
this SSL business.
My serverkey.pem is:
-BEGIN RSA PRIVATE KEY-
some base64 stuff
-END RSA PRIVATE KEY-
My servercert.pem is:
-BEGIN CERTIFICATE-
some base64 stuff
-END CERTIFICATE-
ca_cert.pem is
some VC++ help wanted: can not step into SSL_xxx functions (debug libeay32.dll and ssleay32.dll)
Dear readers, I know, it's great, sunny whether today, but may be someone would kindly help, anyway ;-) *Background:* I'm just debugging some problem around SSL_CTX_load_verify_locations() call in my particular environment. Since I'm not able to find the reason for: openssl.exe s_client -debug -state -connect 192.168.0.192:21 is always reporting: no peer certificate available, so I think it's best to step into SSL_CTX_load_verify_locations() and to see, what files and directories are _really_ tried to load and so on. *Problem:* But I can't step into _any_ BIO_xxx or SSL_xxx functions. VS2005 reports, it has the symbols: \Training\ssl1\debug\libeay32.dll', Symbols loaded. blahblah..\msvcr80d.dll', Symbols loaded. \Training\ssl1\debug\ssleay32.dll', Symbols loaded. *but on pressing F11 (step into), nothing happens!* Already copied all *.pdb to the same directory as my local copies of DLLs are located, also added \openss1_1.0.0.\out32dll to pdb search path. I built OpenSSL 1.0.0 release, as described in INSTALL.W32, using the 'no-asm' and 'debug' options. This created in ./out32dll aside others this: 08.04.2010 19:34 1.363.968 libeay32.dll 08.04.2010 19:34 315.392 ssleay32.dll 08.04.2010 19:34 771.324 libeay32.lib 08.04.2010 19:3456.834 ssleay32.lib 08.04.2010 19:34 1.944.576 libeay32.pdb 08.04.2010 19:34 420.864 ssleay32.pdb 08.04.2010 19:34 385 ssleay32.dll.manifest 08.04.2010 19:34 385 libeay32.dll.manifest 08.04.2010 19:34 466.605 libeay32.exp 08.04.2010 19:3434.068 ssleay32.exp One question: Is the file size okay for really being DEBUG versions? Any hint or help is highly appreciated by Modem Man
Re: some VC++ help wanted: can not step into SSL_xxx functions (debug libeay32.dll and ssleay32.dll)
Mounir IDRASSI wrote: Hi, Try adding the switch /Zi to the CFLAG in the makefile and rebuild the dlls. This is mandatory to create a full program database. I come across the same problem and I solved it with this. The perl scripts should be updated to include this flag for the debug build. YES! Thank you very much, you saved my day!! Works for me! Modem Man On 4/25/2010 1:47 PM, Modem Man wrote: Dear readers, I know, it's great, sunny whether today, but may be someone would kindly help, anyway ;-) *Background:* I'm just debugging some problem around SSL_CTX_load_verify_locations() call in my particular environment. Since I'm not able to find the reason for: openssl.exe s_client -debug -state -connect 192.168.0.192:21 is always reporting: no peer certificate available, so I think it's best to step into SSL_CTX_load_verify_locations() and to see, what files and directories are _really_ tried to load and so on. *Problem:* But I can't step into _any_ BIO_xxx or SSL_xxx functions. VS2005 reports, it has the symbols: \Training\ssl1\debug\libeay32.dll', Symbols loaded. blahblah..\msvcr80d.dll', Symbols loaded. \Training\ssl1\debug\ssleay32.dll', Symbols loaded. *but on pressing F11 (step into), nothing happens!* Already copied all *.pdb to the same directory as my local copies of DLLs are located, also added \openss1_1.0.0.\out32dll to pdb search path. I built OpenSSL 1.0.0 release, as described in INSTALL.W32, using the 'no-asm' and 'debug' options. This created in ./out32dll aside others this: 08.04.2010 19:34 1.363.968 libeay32.dll 08.04.2010 19:34 315.392 ssleay32.dll 08.04.2010 19:34 771.324 libeay32.lib 08.04.2010 19:3456.834 ssleay32.lib 08.04.2010 19:34 1.944.576 libeay32.pdb 08.04.2010 19:34 420.864 ssleay32.pdb 08.04.2010 19:34 385 ssleay32.dll.manifest 08.04.2010 19:34 385 libeay32.dll.manifest 08.04.2010 19:34 466.605 libeay32.exp 08.04.2010 19:3434.068 ssleay32.exp One question: Is the file size okay for really being DEBUG versions? Any hint or help is highly appreciated by Modem Man __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: some VC++ help wanted: can not step into SSL_xxx functions (debug libeay32.dll and ssleay32.dll)
Kyle Hamilton wrote: 'no peer certificate available' is a different error than 'peer certificate did not verify'. This means that the TLS server is running without a certificate. (TLS and SSL do *not* require servers to provide certificates, but they do require that servers must provide certificates before they ask for client authentication, else it's a protocol error.) -Kyle H Thank you for this essential information! Good to know. Am I right to believe this has to do with SSL_CTX_set_verify( ctx, SSL_VERIFY_PEER, verify_cert_foo ); /vs./ SSL_CTX_set_verify( ctx, SSL_VERIFY_NONE, verify_cert_foo ); ? In between I added /Zi to CFLAGS (as Mounir said, .\util\pl\VC-32.pl is the right place) and after this I rebuild the whole OpenSSL 1.0.0 suite again. This made me able to step into SSL_* and to figure out where I used wrong directory names. **One more question:** Is it still a good idea to use: ctx = SSL_CTX_new( SSLv23_method() ) combined with SSL_CTX_set_options( ctx, (SSL_OP_NO_SSLv2 | SSL_OP_ALL) ); to get SSLv3 + TLSv1 on, but SSLv2=off? This is often shown for OpenSSL 0.9.x in the books and I used it. Actually, I get: *openssl.exe s_client -debug -state -connect 192.168.0.192:21 * Loading 'screen' into random state -CONNECTED(0774) write to 0xa626a0 [0xa62700] (124 bytes = 124 (0x7C)) - 80 7a 01 03 01 00 51 00-00 00 20 00 00 39 00 00 .zQ... ..9.. 0010 - 38 00 00 35 00 00 16 00-00 13 00 00 0a 07 00 c0 8..5 0020 - 00 00 33 00 00 32 00 00-2f 00 00 07 05 00 80 03 ..3..2../... 0030 - 00 80 00 00 05 00 00 04-01 00 80 00 00 15 00 00 0040 - 12 00 00 09 06 00 40 00-00 14 00 00 11 00 00 08 ..@. 0050 - 00 00 06 04 00 80 00 00-03 02 00 80 91 a5 45 62 ..Eb 0060 - 1d cb 55 d0 62 e2 95 b6-4f 41 fe 3c e4 c5 43 d1 ..U.b...OA...C. 0070 - 32 d6 04 aa 06 c1 35 00-22 75 3e 09 2.5.u. read from 0xa626a0 [0xa67c60] (7 bytes = 7 (0x7)) - 15 03 01 00 02 02 28 ..( done SSL_connect:before/connect initialization SSL_connect:SSLv2/v3 write client hello A SSL3 alert read:fatal:handshake failure SSL_connect:error in SSLv2/v3 read server hello A 5044:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:.\ssl\s23_clnt.c:596: May I forgot to set accept/connect direction of SLL, before calling BIO_do_handshake(bio)? (pls. note: bio is a chain of buffer + ssl + accept_socket, where buffer + accept_socket already up and running fine). I did read somewhere some command to set ssl direction, but I don't remember it! SSL_state_server/accept() or such? And this is what makes me some more headache. But it's pretty late now and this noon I tried a very good red wine together with my wife, so I think I'll delay further investigations till tomorrow. May be the headache is from the wine? Anyway. If you think my above dump is easy to give next hint for me ... this would be very kindly, again! have a silent night, Modem Man
Re: BIO_do_handshake() little help wanted
Hi Kyle, regarding your hint: SSL[_CTX]_set_cipher_list((is_ctx ? ctx : ssl),STRONG:@STRENGTH) is your friend. I believe it defaults to essentially NONE, but I could be wrong on that one -- I just know that unable to negotiate a shared cipher means that the cipher list sent by the client has a null union with the cipher list supported by the server. with the error I cited in my other mail, I used SSL_CTX_set_cipher_list( ctx, ALL:DEFAULT:LOW ) I checket this by typing openssl ciphers -v ALL:DEFAULT:LOW and saw, this is a list of 50 ciphers. So, for my /experiments/ this should not be the source of problems, right? Of course, a /productive/ quality server shall use STRONG:@STRENGTH. But I think, I'm still far away from reducing some protocol offers. The recent trouble is: SSL_connect:before/connect initialization SSL_connect:SSLv2/v3 write client hello A SSL3 alert read:fatal:handshake failure SSL_connect:error in SSLv2/v3 read server hello A :-( I'd appreciate _any_ further hint or help, next days. with best regards, Modem Man __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Crash bug in 0.9.8n
Thomas J. Hruska schrieb: Running 'openssl s_client' on 0.9.8n without any additional arguments crashes openssl.exe. There is very different behavior between 0.0.8 and 1.0.0 on WinXP Pro SP3: openssl version OpenSSL 0.9.8j 07 Jan 2009 openssl s_client Loading 'screen' into random state - done connect: Bad file descriptor connect:errno=10061 openssl version OpenSSL 1.0.0 29 Mar 2010 openssl s_client Loading 'screen' into random state - done connect: No error connect:errno=0 its no problem for me. Just for information completion. regards, Modem Man __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
BIO_do_handshake() little help wanted
Dear all,
I'm fiddling since two days with BIO_do_handshake(), and always have no
luck.
I'm afraid, it's time to cry for help now.
*Short description:*
After BIO_do_handshake() always returns -1, I always get the message:
/error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher/
from my error printing loop, which is:
while( (code=ERR_get_error_line_data( file, line, data, flags ) ) !=
0 ) {
ERR_error_string_n( code, errX, sizeof(errX) );
syslog( LOG_ERROR, ! %s, errX );
};
*Detailed description:*
The code until the BIO_do_handshake() doing as follows:
1) building a BIO chain, consisting of an accept_socket BIO and a buffer
BIO.
2) accept / pop as usually
3) BIO_gets / BIO_puts, all working fine in non-SSL mode
please note: it is a FTP Server, completely written in OpenSSL
BIO_ and working fine since 2 weeks - until I try to add SSL to my
BIO chain
when we arrive here, it is the 1st command from the sftp client:
4) if seen AUTH TLS or AUTH SSL, I do answering:
234 AUTH command ok; starting SSL connection.\r\n,
this sets the client into SSL mode, too.
Next, I do inserting a SSL BIO by the following sequence:
(stripped error-check here, but can say, all functions returning ok
so far)
SSL_CTX * ctx;
SSL * ssl;
BIO * sslBIO, *bSock;
ctx = SSL_CTX_new( SSLv23_method() );
SSL_CTX_set_options( ctx, (SSL_OP_NO_SSLv2 | SSL_OP_ALL) );
SSL_CTX_set_mode( ctx, SSL_MODE_AUTO_RETRY );
SSL_CTX_set_cipher_list( ctx, ALL:DEFAULT:LOW ); /* also not
working: ALL:!ADH:!LOW:!EXP:!MD5 */
SSL_CTX_set_default_verify_paths( ctx );
// CAFILE is /debug/servercert.pem
// CAPATH is ./debug path itself, there is also serverkey.pem
SSL_CTX_load_verify_locations( ctx, CAFILE, CAPATH ) );
SSL_CTX_set_verify( ctx, SSL_VERIFY_PEER, verify_cert_callback_foo );
SSL_CTX_set_verify_depth( ctx, VERIFY_DEPTH + 1 );
sslBIO = BIO_new_ssl( ctx, 0 /*server*/ );
BIO_get_ssl(sslBIO, ssl);
SSL_set_mode(ssl, SSL_MODE_AUTO_RETRY);
bBuff = myContext-bio; /* this is the bio I'm already using:
BUFFER+ACCEPT_SOCKET */
bSock = BIO_pop( bBuff ); /* get the raw socket-bio */
BIO_set_callback( sslBIO, BIO_debug_callback_foo );
/* reassemble the chain, now with SSL in the middle: */
myContext-bio = BIO_push( bBuff, BIO_push( sslBIO, bSock ) );
BIO_do_handshake( sslBIO );
!Bang! here I die
Need to say: Windows XP pro SP3, Client is TotalCommander 7.02 with
built in sftp via OpenSSL
Any hint? Help? Suggestion?
Any knowledge of Bug in Totalcommander?
Any Idea of another cost-free sftp client, I can try?
I would appreciate EVERYTHING that brings me a step further...
with best regards,
Modem Man
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Win32 OPENSSL_USE_APPLINK usage
Hi Andy Polyakov, you kindly made some comments on my topic. I understand your comments in the meaning of: Please do not try to break fopen()/setlocale() compatibility of BIO_new_file(). This is a good idea, no doubt! But let me go into deep, by quoting your quotes... MM - For Win32 and Win32_WinCE the conversion can be done with MM FormatMessage() API. It's allways available. AP ??? So as MultiByteToWideChar... A. Right, this is my mistake. I mentioned the same: MultiByteToWideChar(). MM why not adding the following to BIO_new_file()? MM - BIO interface still uses char * (meaning latin ASCII 0x20..0x7F) AP This is incorrect assumption. BIO_new_file and fopen allow for AP characters recognized as valid in current locale, which is not AP necessarily limited to ASCII. In other words it's perfectly possible to AP BIO_new_file as well as to fopen file with international characters in AP its name, but the set of allowed non-ASCII characters varies. I have very bad experience with filenames containing locale depending characters. This is only running in homogeneous architectures without border crossing networks. Please note, we have reached the year 2010 ;-) So it's mostly unlikely to handle filenames the national (racialist) way all times well. May be, I'm unusually aggressive about this, because my surname contains the German 'sz ligature' letter, or 0xDF in /one/ of your locales, 0xF1 in /another/ MM on all platforms supporting MM wfopen or _wfopen AP What are the platforms supporting wfopen? Among those supported by AP OpenSSL? It's Windows platforms. I don't know. For Windows XYZ: yes. For others: who knows? How do other platforms handle such mixed character filenames? All doing still the racialist way? I can't believe this! Well, linux may be. But HPUX? VMS? All the same? I often get files with basically German names (conatining Umlauts and sz ligature), then completed with Chinese or Cyrillic suffixes. Or I get FTP directories filled up with files from Germany and Denmark (which are indeed _not_ from the same locale). All wchar_t functions and utf8 functions do handle this perfectly. But the locale shit like 1974's fopen() can't deal with such files, right? In my eyes, locale is a dying species. Or at least - it should be! The future is either a mix between UTF8 and UCS16 for systems which using wchar_t, so UTF8 is the 8-bit-interfacing format, while internally using UCS16 - or clean UTF8. Anyway, in summary, we can see two critical requirements: a) do not break fopen() / setlocale() compatibility of BIO_new_file() b) support seasonable file naming (3rd millennium!) then c) we found conclusion to _not_ change BIO_new_file() at all. H. Give it another try? Another well approved way is to create W or U variants of each relevant API, like: BIO_new_fileW( const wchar_t *filename, const wchar_t *mode ); or BIO_new_fileU( const char *filenameUTF8, const char *mode ); The first is the way, Microsoft did for their API. The latter is the way, I use to port locale-depending old code into current millennium. How about this? with best regards, Modem-Man __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
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 User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: ERROR LINK2019
Hi, 芦翔 please check, if you are using the right include path fpr the right .h files. After calling this: C:\From_Here\openssl.1.0.0\ perl Configure VC-WIN32 no-asm --prefix=c:/to_here/ssl C:\From_Here\openssl.1.0.0\ ms\do_ms you DON'T should use: -I C:\From_Here\openssl.1.0.0\include (or Additional Include directories in VS GUI). It's because the .h files there all consisting of incomplete files, just containing the line Link: filename.h. Instead, look into \ (root directory), there is some new directory tree /usr/bin/to_here/ssl (or similiar, I don't remember the exact location). So better use -I /usr/bin/to_here/ssl (or whatever exact to_here location is). Same for *.LIB (Additional Linker Dependencies) If this helps, please report. Otherwise also. M.M. Dear all, I am trying to add the security flavor to an application. To achieve this objective, I wrote the codes to establish a security tunnel between the server and the client with VC2008. When I build the whole project, there are tens of similar errors. All of them are as follows: SSLServer.obj : error LNK2019: unresolved external symbol _BIO_free referenced in function int __cdecl SSL_CTX_use_PrivateKey_file_pass(struct ssl_ctx_st *,char *,char *) (?SSL_CTX_use_PrivateKey_file_pass@@YAHPAUssl_ctx_st@@p...@z mailto:?SSL_CTX_use_PrivateKey_file_pass@@YAHPAUssl_ctx_st@@p...@z) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: ERROR LINK2019
Hi 芦翔,
I also used mixed C / C++ Project and did not used the probably well known
#ifdef __cplusplus
extern C {
#endif
#include openssl\.h
#ifdef __cplusplus
}
#endif
stuff. It worked for me without this. Used VS 2005, which surely has
same behaviour as VS 2008.
M.M.
hi,
Thank you for your notes. Yes, my code is composed of both C and C++
code. For the openssl part, it is programed by C. And the other part
is from C++. Should I only use extern for those C-realated
#include, or all the C code should be embraced in the extern?
Thank you so much.
Best Regards,
Xiang
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: ERROR LINK2019
Hi 芦翔, the way Windows/C is using the SSL Lib here, is a so called Dynamic Link Library via IMPLIB loading. This means, each DLL file has a corresponding LIB file which is statically to be linked together with your source code's OBJ files to become your EXE file. But this LIB is only a so called stub, a library which does nothing else than being a proxy/gateway between your code and the SSL's DLLs. As you can imagine now, your EXE already has the LIBEAY.LIB linked. Your EXE is starting and before calling WinMain() / main() / _tmain() it initializes own startup code and LIB's startup code. The latter now searches it's corresponding DLL file to make its job of beeing the proxy. And in your case, it reports not beeing able to locate this DLL. Looks like your application just don't know where to locate the LIBEAY.DLL. 1st, you should know, where on your computer this particular file resides. 2nd, you should learn, how your platform is searching for DLLs. Hint: Search order within windows is: 1st) current directory (usually, where your .EXE resides) 2nd) each entry of %PATH% environment variable, from left to right. Finally, you could also read SSL package's INSTALL.W32 and ms\*.bat files to learn how to skip DLL usage and how to to link complete .LIB (not the small IMPLIB). This would be a so called Static Library without any DLL linkage. And very finally, inc32 might be the better include directory than include? Read _complete_ INSTALL.W32, to learn if this is true for your environment, or not. Hoping you can also help me somewhen in future, M.M. Dear Modem, Thank you for your instructions. I have overcomed the problem by putting extern in my code, and rebuild the openssl lib as your notes. I really appreciate the helps from you and Wiliam. Now, I can build my application. However, after building the application, it pops a message box, which says that This application has failed to start because LIBEAY32.dll was not found. Re-installing the application may fix this problem. I don't know what happens. I am not sure if I need re-compile the openssl code for a dll file, in addition, how can I use the compiled dll file. Suggestions will be really appreciated. Thank you. Best Regards, Xiang __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
OpenSSL 1.0.0 patch for enabling *:123 host syntax and ephemeral ports with Win32
Hi,
I found and fixed a small bug in crypto\bio\b_sock.c and want to ask
where to post the patch / fix.
please note:
I can not guarantee of production grade quality of my fix, but it works
pretty well with my implementation of an FTP server.
regards,
Maik,
the modem-man
B.T.W.: what is preferred diff format here? I used diff -bw -u. Okay?
--- 1.0.0\b_sock.c Thu Jan 07 14:15:40 2010
+++ 1.0.0.patchw32asteriskhost\b_sock.c Fri Apr 09 21:02:18 2010
@@ -672,7 +672,21 @@
#endif
}
else if (h[0]=='*' h[1]=='\0')
+ {
+# ifdef _WIN32 /* modem-man patch, sure for windows. not sure for other OS
*/
+ /* h=0.0.0.0; */ /* quick hack, but dirty! */
+ hint.ai_flags |= AI_PASSIVE; /* better way of '*'
handling! */
+# else /* modem-man patch */
h=NULL;
+# endif /* modem-man patch */
+ }
+ }
+ if (p (p[0]=='*' p[1]=='\0'))
+ {
+# ifdef _WIN32 /* modem-man patch */
+ p=0; /* ephemeral port number */
+ hint.ai_flags |= AI_PASSIVE; /* better way of '*'
handling! */
+# endif /* modem-man patch */
}
if ((*p_getaddrinfo.f)(h,p,hint,res)) break;
