[openssl-users] Strange behaviour with Chrome (client OS = WinXP x64) ...
Hello, can someone please try the following website with Google Chrome - I use the latest release: Version 39.0.2171.99 m - https://banking.ing-diba.at/ (an electronic Banking site) with the following policy enabled: RequireOnlineRevocationChecksForLocalAnchors = 1 with this banking site I get the following error from Google Chrome Your connection is not private Attackers might be trying to steal your information from banking.ing-diba.at (for example, passwords, messages, or credit cards). with the following banking sites of other banks I have no troubles: https://ebanking.easybank.at/ or https://banking.raiffeisen.at/ without enabling the policy above or not setting at all, this banking site works, but the symbol it shows differs; it is the same as if a man-in-the-middle like SSL-Bump would be between; Google chrome uses the same cert store as IE, and with IE there is no connection problem, only another thing the banking site is telling: the browser is out dated, of course IE 7 the IE even shows a green bar when connecting to this banking site ... can someone please tell me what is there special with this banking site: https://banking.ing-diba.at/ ? I'm using SSL bump with the exception of banking sites, the specific part of the squid.conf looks like this: acl ssl_bump_domains_bankingsites dstdomain banking.raiffeisen.at banking.ing-diba.at ebanking.easybank.at services.kepler.at www.kepler.at www.rcb.at acl ssl_bump_domains_msftupdates dstdomain .update.microsoft.com ssl_bump none ssl_bump_domains_bankingsites ssl_bump none ssl_bump_domains_msftupdates ssl_bump server-first all sslproxy_cert_error allow all sslproxy_cipher HIGH:MEDIUM:!AECDH:!ADH:!DSS:!SSLv2:+SSLv3:+3DES:!MD5 sslproxy_flags DONT_VERIFY_PEER,NO_DEFAULT_CA sslproxy_options NO_SSLv2 NO_SSLv3 sslcrtd_program /usr/lib64/squid/ssl_crtd -s /var/local/squid/ssl_db -M 16MB sslcrtd_children 8 http_port 3128 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=16MB cert=/etc/squid/cert/squid.pem options=NO_SSLv2,SINGLE_DH_USE dhparams=/etc/squid/cert/dhparam.pem # squid.pem contains both cert+key I'm using my own CA, this means this SSL-bump CA cert is signed by my root CA certificate; what is missing, wrong, ... so that this one banking site will work ...? the SSL-bump CA certificate contain this: Authority Information Access: OCSP - URI:#url-to-ocsp# CA Issuers - URI:#url-to-root-cert# and X509v3 CRL Distribution Points: Full Name: URI:#url-to-crl# everything is working, the OCSP, the root-cert, and the CRL ... what causes Google Chrome producing the mentioned error above, when activating this mentioned policy? the question to squid specialists: was it a good idea signing the SSL-bump CA certificate with the root certificate of my CA? Thanks -- Best regards, Walter H. smime.p7s Description: S/MIME Cryptographic Signature ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] OpenSSL 'verify' command and c_ rehash script on Cygwin
-- Forwarded message -- From: Deepak dpb795...@gmail.com Date: Jan 31, 2015 8:05 AM Subject: OpenSSL 'verify' command and c_ rehash script on Cygwin To: openssl-users@openssl.org Cc: Hi, Can following behaviour be confirmed as expected? OpenSSL verify test (test_verify) fails Env- c_rehash run using Cygwin. Run c_rehash on /path/to/certs/demo Cmd - openssl verify -CApath ../certs/demo ../certs/demo/*.pem Cause - Symbolic links (from hash.0 to file.pem) created by c_rehash when run with Cygwin could not be read by OpenSSL.exe verify command. Result - Error 20: could read issuer certificate OpenSSL.exe fails to establish certificate chain. Workaround - Modify c_rehash to use MS API 'mklink' Thank You. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] What is the best practise for shutdown SSL connections?
On Sun, Feb 01, 2015 at 11:36:20PM +0300, Serj wrote: 1. Return values for SSL_shutdown() 0 initially if shutdown alert sent, but not yet received from the peer. I never get 2 as a return value! Why do you expect 2? [ Note, something is screwing up itemized lists in the on-line documentation. Instead of showing item labels, item numbers are showing up instead. ] The nroff manpage says: RETURN VALUES The following return values can occur: 0 The shutdown is not yet finished. Call SSL_shutdown() for a second time, if a bidirectional shutdown shall be performed. The output of SSL_get_error(3) may be misleading, as an erroneous SSL_ERROR_SYSCALL may be flagged even though no error occurred. 1 The shutdown was successfully completed. The close notify alert was sent and the peer's close notify alert was received. -1 The shutdown was not successful because a fatal error occurred either at the protocol level or a connection failure occurred. It can also occur if action is need to continue the operation for non-blocking BIOs. Call SSL_get_error(3) with the return value ret to find out the reason. 2. What is the best practise for shutdown SSL connections for CLIENT? Call ssl_shutdown() and if it returns 0, call it again processing WANT_READ/WANT_WRITE as required. -- Viktor. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] What is the best practise for shutdown SSL connections?
Hello, What is the best practise for shutdown SSL connections? When client and server both not mine. For example, http client or server. I have read: https://www.openssl.org/docs/ssl/SSL_shutdown.html https://www.openssl.org/docs/ssl/SSL_set_shutdown.html I use non-blocking sockets and create sockets manually, then with BIO_new_socket() and SSL_set_bio() associate them with SSL object. I have 3 themes and corresponding questions: 1. Return values for SSL_shutdown() I never get 2 as a return value! Only 1 as successful then SSL_SENT_SHUTDOWN and SSL_RECEIVED_SHUTDOWN are both set. Maybe something wrong at the documentation? 2. What is the best practise for shutdown SSL connections for CLIENT? As I understand unidirectional shutdown for client is more suitable, doesn't require special work for waiting close_notify. But we must be sure that server got a close_notify - this is the question! So, the code for CLIENT: //all data were obtained from the server SSL_shutdown(ssl); //here we must be sure that close_notify alert is gotten by server //... closesocket(s); How to do this check: server got the close_notify alert? What is the best practise? I see that SSL_get_shutdown() returns SSL_SENT_SHUTDOWN immediatly after we have called SSL_shutdown() first time, so it only sets the flag after sending close_notify but doesn't wait. 3. What is the best practise for shutdown SSL connections for SERVER? As I understand SERVER must get close_notify from client otherwise it will not be able to save a session, am i right? And the session will be invalid in this case. So, for server the code is: //all data has been sent to the client SSL_shutdown(ssl); //will not be superfluous //here we must wait a close_notify alert from client //we can do this by examine flag SSL_RECEIVED_SHUTDOWN with SSL_get_shutdown() //... //and only after this we can safely close the connection closesocket(s); I will be very glad if these 3 themes and corresponding questions will not go unanswered! -- Best Regards, Serj ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] What is the best practise for shutdown SSL connections?
On Mon, Feb 02, 2015 at 12:28:12AM +0300, Serj wrote: Why do you expect 2? ?[ Note, something is screwing up itemized lists in the on-line documentation. ?Instead of showing item labels, item numbers are showing up instead. ] Here: https://www.openssl.org/docs/ssl/SSL_shutdown.html I see only this: - RETURN VALUES The following return values can occur: 1. The shutdown is not yet finished. Call SSL_shutdown() for a second time, if a bidirectional shutdown shall be performed. The output of SSL_get_error may be misleading, as an erroneous SSL_ERROR_SYSCALL may be flagged even though no error occurred. 2. The shutdown was successfully completed. The close notify alert was sent and the peer's close notify alert was received. 0 The formatting of itemized lists in the on-line HTML is broken. -- Viktor. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] What is the best practise for shutdown SSL connections?
Hi, Viktor. 01.02.2015, 23:50, Viktor Dukhovni openssl-us...@dukhovni.org: On Sun, Feb 01, 2015 at 11:36:20PM +0300, Serj wrote: 1. Return values for SSL_shutdown() 0 initially if shutdown alert sent, but not yet received from the peer. I never get 2 as a return value! Why do you expect 2? [ Note, something is screwing up itemized lists in the on-line documentation. Instead of showing item labels, item numbers are showing up instead. ] Here: https://www.openssl.org/docs/ssl/SSL_shutdown.html I see only this: - RETURN VALUES The following return values can occur: 1. The shutdown is not yet finished. Call SSL_shutdown() for a second time, if a bidirectional shutdown shall be performed. The output of SSL_get_error may be misleading, as an erroneous SSL_ERROR_SYSCALL may be flagged even though no error occurred. 2. The shutdown was successfully completed. The close notify alert was sent and the peer's close notify alert was received. 0 The shutdown was not successful because a fatal error occurred either at the protocol level or a connection failure occurred. It can also occur if action is need to continue the operation for non-blocking BIOs. Call SSL_get_error with the return value ret to find out the reason. - The nroff manpage says: RETURN VALUES The following return values can occur: 0 The shutdown is not yet finished. Call SSL_shutdown() for a second time, if a bidirectional shutdown shall be performed. The output of SSL_get_error(3) may be misleading, as an erroneous SSL_ERROR_SYSCALL may be flagged even though no error occurred. 1 The shutdown was successfully completed. The close notify alert was sent and the peer's close notify alert was received. -1 The shutdown was not successful because a fatal error occurred either at the protocol level or a connection failure occurred. It can also occur if action is need to continue the operation for non-blocking BIOs. Call SSL_get_error(3) with the return value ret to find out the reason. Seems to be this is right. This is exactly what I wanted to see here: https://www.openssl.org/docs/ssl/SSL_shutdown.html 2. What is the best practise for shutdown SSL connections for CLIENT? Call ssl_shutdown() and if it returns 0, call it again processing WANT_READ/WANT_WRITE as required. I use non-blocking sockets. That's why I got -1 as return value after first ssl_shutdown(). I process WANT_READ/WANT_WRITE. But some servers don't send close_notify, so we never got a 1 as a return value. We must be sure that server got a close_notify - this is the question! What is the best practise for that? -- Best Regards, Serj ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] SSL/TLS sessions of client
Hello, I want to use only internal cache right now. SSL_SESS_CACHE_CLIENT is not set by default. As I understand for client we must: 1. Set SSL_SESS_CACHE_CLIENT flag with SSL_CTX_set_session_cache_mode() 2. Manually save SSL_SESSION object to be able to choose session with SSL_set_session() next time or we can only save a pointer to SSL_SESSION object with SSL_get1_session() (because all data already will be kept in memory until we explicitly call SSL_SESSION_free()) and then we can give this pointer to the SSL_set_session()? -- Best Regards, Serj ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] What is the best practise for shutdown SSL connections?
On Mon, Feb 02, 2015 at 01:32:42AM +0300, Serj wrote: But what about the best practice for shutdown of connection on the client side? http://tools.ietf.org/html/rfc5246#section-7.2.1 And what about the best practice for shutdown of connection on the server side? Is it mandatory to wait close_notify from client to be able to save valid session for this client or not? If server close the connection after all data has been sent to the client and don't receive close_notify, will be the session kept? http://tools.ietf.org/html/rfc5246#section-7.2.1 -- Viktor. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] What is the best practise for shutdown SSL connections?
02.02.2015, 01:13, Viktor Dukhovni openssl-us...@dukhovni.org: The formatting of itemized lists in the on-line HTML is broken. Ok. But what about the best practise for shutdown of connection on the client side? Server can don't send close notify alert. And what about the best practise for shutdown of connection on the server side? Is it mandatory to wait close_notify from client to be able to save valid session for this client or not? If server close the connection after all data has been sent to the client and don't receive close_notify, will be the session kept? -- Best Regards, Serj ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] ECDHE-ECDSA certificate returning with no shared cipher error
Hello Openssl users, Am facing an issue of no shared cipher error during SSL Handshake, when tried to negotiate ECDHE cipher suite. We are using openssl-1.0.1j version. Can you please share your thoughts? Following are the logs during SSL Handshake. Server has 2 from 0xE29690E0: 0x10B42900:ECDHE-ECDSA-AES256-SHA 0x10B428D0:ECDHE-ECDSA-AES128-SHA Client sent 2 from 0xE442F5B0: 0x10B42900:ECDHE-ECDSA-AES256-SHA 0x10B428D0:ECDHE-ECDSA-AES128-SHA rt=0 rte=0 dht=1 ecdht=1 re=1 ree=1 rs=0 ds=0 dhr=0 dhd=0 0:[0080:0040:0089:0005]0x10B42900:ECDHE-ECDSA-AES256-SHA rt=0 rte=0 dht=1 ecdht=1 re=1 ree=1 rs=0 ds=0 dhr=0 dhd=0 0:[0080:0040:0089:0005]0x10B428D0:ECDHE-ECDSA-AES128-SHA *Feb 2 01:00:46.884: SSL_accept:before/accept initialization *Feb 2 01:00:46.884: SSL_accept:would block on read in SSLv3 read client hello B *Feb 2 01:00:47.892: TLS 1.2 Handshake [length 0092], ClientHello *Feb 2 01:00:47.892: 01 00 00 8E 03 03 C3 CB 15 58 20 B9 49 1D 73 C7 *Feb 2 01:00:47.892: F8 C1 4D 31 10 A1 B6 D9 62 9E DF 91 A8 DC 8F 79 *Feb 2 01:00:47.892: 95 79 20 55 AC CF 00 00 06 C0 0A C0 09 00 FF 01 *Feb 2 01:00:47.893: 00 00 5F 00 0B 00 04 03 00 01 02 00 0A 00 34 00 *Feb 2 01:00:47.893: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 *Feb 2 01:00:47.893: 0A 00 16 00 17 00 08 00 06 00 07 00 14 00 15 00 *Feb 2 01:00:47.893: 04 00 05 00 12 00 13 00 01 00 02 00 03 00 0F 00 *Feb 2 01:00:47.893: 10 00 11 00 0D 00 16 00 14 06 01 06 03 05 01 05 *Feb 2 01:00:47.893: 03 04 01 04 03 03 01 03 03 02 01 02 03 00 0F 00 *Feb 2 01:00:47.893: 01 01 *Feb 2 01:00:47.893: TLS client extension EC point formats (id=11), len=4 *Feb 2 01:00:47.893: 03 00 01 02 *Feb 2 01:00:47.893: TLS client extension elliptic curves (id=10), len=52 *Feb 2 01:00:47.893: 00 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 *Feb 2 01:00:47.893: 00 0A 00 16 00 17 00 08 00 06 00 07 00 14 00 15 *Feb 2 01:00:47.893: 00 04 00 05 00 12 00 13 00 01 00 02 00 03 00 0F *Feb 2 01:00:47.893: 00 10 00 11 *Feb 2 01:00:47.893: TLS client extension signature algorithms (id=13), len=22 *Feb 2 01:00:47.893: 00 14 06 01 06 03 05 01 05 03 04 01 04 03 03 01 *Feb 2 01:00:47.893: 03 03 02 01 02 03 *Feb 2 01:00:47.893: TLS client extension heartbeat (id=15), len=1 *Feb 2 01:00:47.893: 01 *Feb 2 01:00:47.894: TLS 1.2 Alert [length 0002], fatal handshake_failure *Feb 2 01:00:47.894: 02 28 *Feb 2 01:00:47.894: Router# *Feb 2 01:00:47.894: SSL3 alert write:fatal:handshake failure *Feb 2 01:00:47.894: SSL_accept:error in SSLv3 read client hello C *Feb 2 01:00:47.894: 3854049196:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher s3_srvr.c:1381: Have updated with temporary ECDH callback during SSL Server initialization. ECDSA certificate is being signed using openssl commands. Am not seeing any issue with RSA baesd ciphers. But only with ECDSA based ciphers having problem on my setup. Can you please share will the certificate loading is something different than RSA? Thanks, Rajeswari. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] What is the best practise for shutdown SSL connections?
Hi, Viktor.
02.02.2015, 02:08, Viktor Dukhovni openssl-us...@dukhovni.org:
On Mon, Feb 02, 2015 at 01:32:42AM +0300, Serj wrote:
But what about the best practice for shutdown of connection on the client
side?
http://tools.ietf.org/html/rfc5246#section-7.2.1
I read RFC. Have read 7.2.1. Closure Alerts once again.
But this is the normative document. I ask: what in practise in terms of OpenSSL
API?
As I already said some servers don't send close_notify and just close the
connection.
So I think the shutdown algorithm for SSL client must be the following:
-
//...
//all data was obtained from the server
if (SSL_shutdown(ssl)==1)
{
closesocket(s)
goto l_shutdown_complete;
}
shutdown(s,SD_SEND);
//set timeout for getting close_notify from SERVER
//in the cycle... waiting events from socket or timeout (which comes first):
//
//1. process SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE (in this case only
SSL_ERROR_WANT_READ because seems to be SSL_shutdown() send close_notify
alert to SERVER), call SSL_shutdown() once again and examine it's return value
for 1 OR examine SSL_get_shutdown() for
(SSL_SENT_SHUTDOWN|SSL_RECEIVED_SHUTDOWN)
//
//2. Wait FD_CLOSE
//
//3. Timeout
//if one of three happens closesocket(s)
-
And what about the best practice for shutdown of connection on the server
side? Is it mandatory to wait close_notify from client to be able to
save valid session for this client or not? If server close the connection
after all data has been sent to the client and don't receive close_notify,
will be the session kept?
http://tools.ietf.org/html/rfc5246#section-7.2.1
I ask: what in practise in terms of OpenSSL API?
If SERVER close the connection after all data has been sent to the client and
will not wait for close_notify alert from CLIENT, will be the session kept
and valid in OpenSLL API?
I mean, can CLIENT then reuse this session, if it doesn't send close_notify
alert? Or this session will be invalid?
--
Best Regards,
Serj
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
