Re: [squid-dev] [PATCH] sslproxy_options in peek-and-splice mode
On 02/17/2015 02:49 AM, Amos Jeffries wrote: On 14/02/2015 8:25 a.m., Amos Jeffries wrote: On 13/02/2015 11:52 p.m., Tsantilas Christos wrote: A new patch, which also adds a Must clause for bumping step in Ssl::PeerConnector::initializeSsl method. Was applied as trunk rev.13928 yep, sorry Amos ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
Re: [squid-dev] [PATCH] sslproxy_options in peek-and-splice mode
On 14/02/2015 8:25 a.m., Amos Jeffries wrote: > On 13/02/2015 11:52 p.m., Tsantilas Christos wrote: >> >> A new patch, which also adds a Must clause for bumping step in >> Ssl::PeerConnector::initializeSsl method. >> > > Was applied as trunk rev.13928 Amos ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
Re: [squid-dev] [PATCH] sslproxy_options in peek-and-splice mode
On 13/02/2015 11:52 p.m., Tsantilas Christos wrote: > > A new patch, which also adds a Must clause for bumping step in > Ssl::PeerConnector::initializeSsl method. > +1. Amos ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
Re: [squid-dev] [PATCH] sslproxy_options in peek-and-splice mode
A new patch, which also adds a Must clause for bumping step in Ssl::PeerConnector::initializeSsl method. On 02/12/2015 06:43 PM, Amos Jeffries wrote: On 13/02/2015 4:51 a.m., ich also adds a Must clasTsantilas Christos wrote: On 02/12/2015 05:33 PM, Amos Jeffries wrote: On 13/02/2015 3:34 a.m., Tsantilas Christos wrote: On 02/12/2015 01:48 PM, Amos Jeffries wrote: On 12/02/2015 11:31 p.m., Tsantilas Christos wrote: On 02/11/2015 09:48 PM, Amos Jeffries wrote: On 12/02/2015 12:45 a.m., Tsantilas Christos wrote: On 02/11/2015 01:54 AM, Amos Jeffries wrote: On 9/02/2015 6:43 a.m., Tsantilas Christos wrote: Bug description: - Squid sslproxy_options deny the use of TLSv1_2 SSL protocol: sslproxy_options NO_TLSv1_2 - Squid uses peek mode for bumped connections. - Web client sends an TLSv1_2 hello message and squid in peek mode, forwards the client hello message to server - Web server respond with an TLSv1_2 hello message - Squid while parsing server hello message aborts with an error because sslproxy_options deny the use ot TLSv1_2 protocol. This patch fixes squid to ignore sslproxy_options in peek or stare bumping mode. As I understand it the action of applying the options to the context removes from the context cipher references etc which are not possible. Since peek and stare are non-final states I can easily imagine that OpenSSL library negotiates ciphers which the options would otherwise prohibit. Then when the options get applied to the context it find itself using an algorithm which does not exist. The context SSL_CTX objects are bases to create the SSL objects which are responsible for the negotiation with the other side (server in this case). The SSL created, inherits the options from CTXa nd we are adding our options to SSL object. The SSL library will use these options to build client hello message, parse server hello message and select algorithms/ciphers and other features to establish SSL connection. In my patch the options applied to the squid client SSL objects immediately after created, in the case of bump-server-first, or bump-client-first. In the cases of peek or stare we are not setting any options. This is because we are sending a hello message which is the same or similar with the client hello message, so we can not apply options. Else the peek or stare will fail... What I means is the code flow is roughly like this yes? 1) bump 2) splice 3) peek then bump 4) stare then bump 5) peek then splice 6) stare then splice In which of those cases are the options set? all cases ending in bump or splice. The important factor here is the bumping step. in bump case (1,3,4) - if the decision is to bump in bumpStep1 or bumpStep2 then the squid SSL client options are set. - If the decision for bumping taken in bumpStep3, the the squid SSL client options are NOT set. in splice case (2,5 or 6) : - if we splice on bumpStep1 or on bumpStep2, then we are not using squid SSL client code at all, so the options does not play any role on this case. - If we splice on bumpStep3 we have use squid SSL client, but in this case the options are not set. After the bumpStep2 completed we have received the client hello message, but we do not sent any response (server hello). At the same time we are starting to initiate the connection to the SSL server. This is mean that we are going to set SSL client hello message which is depends on SSL client code. So: - If we know that we will going to bump the connection, we can safely set SSL client options. This is because the squid SSL client will initiate a normal SSL connection. - If we are going to stare, or peek then the client hello message we are going to sent must be similar to the client-to-squid SSL hello message. In this case we can not control SSL features using options, else the SSL negotiation will fail. So you're saying the src/ssl/PeerConnector.cc else-condition never gets run after a peek and/or stare ? Do you mean the "if (csd->sslBumpMode == Ssl::bumpPeek || csd->sslBumpMode == Ssl::bumpStare)" ? I mean the: } else { +// Set client SSL options +SSL_set_options(ssl, ::Config.ssl_client.parsedOptions); + Yes the "else" never gets run when peek or stare mode selected in bumpStep2 bumping step. Then please add a Must(step <= 2) check at the start of that else condition right before setting the SSL client options. If that works properly I am happy for this to go in. Requires a code like the following: Must(csd->sslServerBump()->step<=Ssl::bumpStep2); Specifically: Must( !csd->sslServerBump() || csd->sslServerBump()->step <= Ssl::bumpStep2 ); This is will not work. In client-first bumping mode or in server-first bumping mode where we are not applying the peek-and-splice procedure the step is not updated. Which would make step 0 or 1 for client-first right? that is fine. For server-first
Re: [squid-dev] [PATCH] sslproxy_options in peek-and-splice mode
On 13/02/2015 4:51 a.m., Tsantilas Christos wrote: > On 02/12/2015 05:33 PM, Amos Jeffries wrote: >> On 13/02/2015 3:34 a.m., Tsantilas Christos wrote: >>> On 02/12/2015 01:48 PM, Amos Jeffries wrote: On 12/02/2015 11:31 p.m., Tsantilas Christos wrote: > On 02/11/2015 09:48 PM, Amos Jeffries wrote: >> On 12/02/2015 12:45 a.m., Tsantilas Christos wrote: >>> On 02/11/2015 01:54 AM, Amos Jeffries wrote: On 9/02/2015 6:43 a.m., Tsantilas Christos wrote: > Bug description: > > - Squid sslproxy_options deny the use of TLSv1_2 SSL > protocol: >sslproxy_options NO_TLSv1_2 > - Squid uses peek mode for bumped connections. > - Web client sends an TLSv1_2 hello message and squid in > peek > mode, > forwards the client hello message to server > - Web server respond with an TLSv1_2 hello message > - Squid while parsing server hello message aborts with an > error > because sslproxy_options deny the use ot TLSv1_2 protocol. > > This patch fixes squid to ignore sslproxy_options in peek or stare > bumping mode. As I understand it the action of applying the options to the context removes from the context cipher references etc which are not possible. Since peek and stare are non-final states I can easily imagine that OpenSSL library negotiates ciphers which the options would otherwise prohibit. Then when the options get applied to the context it find itself using an algorithm which does not exist. >>> >>> The context SSL_CTX objects are bases to create the SSL objects >>> which >>> are responsible for the negotiation with the other side (server in >>> this >>> case). >>> The SSL created, inherits the options from CTXa nd we are adding our >>> options to SSL object. >>> The SSL library will use these options to build client hello >>> message, >>> parse server hello message and select algorithms/ciphers and other >>> features to establish SSL connection. >>> >>> In my patch the options applied to the squid client SSL objects >>> immediately after created, in the case of bump-server-first, or >>> bump-client-first. >>> >>> In the cases of peek or stare we are not setting any options. >>> This is >>> because we are sending a hello message which is the same or similar >>> with >>> the client hello message, so we can not apply options. Else the >>> peek or >>> stare will fail... >>> >> >> What I means is the code flow is roughly like this yes? >> >> 1) bump >> 2) splice >> 3) peek then bump >> 4) stare then bump >> 5) peek then splice >> 6) stare then splice >> >> In which of those cases are the options set? >> all cases ending in bump or splice. > > The important factor here is the bumping step. > in bump case (1,3,4) >- if the decision is to bump in bumpStep1 or bumpStep2 then the > squid > SSL client options are set. >- If the decision for bumping taken in bumpStep3, the the squid SSL > client options are NOT set. > > in splice case (2,5 or 6) : >- if we splice on bumpStep1 or on bumpStep2, then we are not using > squid SSL client code at all, so the options does not play any > role on > this case. >- If we splice on bumpStep3 we have use squid SSL client, but in > this > case the options are not set. > > > After the bumpStep2 completed we have received the client hello > message, > but we do not sent any response (server hello). At the same time we > are > starting to initiate the connection to the SSL server. This is mean > that > we are going to set SSL client hello message which is depends on SSL > client code. So: > - If we know that we will going to bump the connection, we can > safely > set SSL client options. This is because the squid SSL client will > initiate a normal SSL connection. > - If we are going to stare, or peek then the client hello > message we > are going to sent must be similar to the client-to-squid SSL hello > message. In this case we can not control SSL features using options, > else the SSL negotiation will fail. So you're saying the src/ssl/PeerConnector.cc else-condition never gets run after a peek and/or stare ? >>> >>> Do you mean the "if (csd->sslBumpMode == Ssl::bumpPeek || >>> csd->sslBumpMode == Ssl::bumpStare)" ? >> >> >> I mean the: >> >> } else { >> +// Set client SSL options >> +SSL_set_options(ssl, ::Config.ssl_client.parsedOptions); >> + >> >> >>> >>> Yes the "else" never gets run when peek or stare mode selected in >>> bumpStep2 bum
Re: [squid-dev] [PATCH] sslproxy_options in peek-and-splice mode
On 02/12/2015 05:33 PM, Amos Jeffries wrote: On 13/02/2015 3:34 a.m., Tsantilas Christos wrote: On 02/12/2015 01:48 PM, Amos Jeffries wrote: On 12/02/2015 11:31 p.m., Tsantilas Christos wrote: On 02/11/2015 09:48 PM, Amos Jeffries wrote: On 12/02/2015 12:45 a.m., Tsantilas Christos wrote: On 02/11/2015 01:54 AM, Amos Jeffries wrote: On 9/02/2015 6:43 a.m., Tsantilas Christos wrote: Bug description: - Squid sslproxy_options deny the use of TLSv1_2 SSL protocol: sslproxy_options NO_TLSv1_2 - Squid uses peek mode for bumped connections. - Web client sends an TLSv1_2 hello message and squid in peek mode, forwards the client hello message to server - Web server respond with an TLSv1_2 hello message - Squid while parsing server hello message aborts with an error because sslproxy_options deny the use ot TLSv1_2 protocol. This patch fixes squid to ignore sslproxy_options in peek or stare bumping mode. As I understand it the action of applying the options to the context removes from the context cipher references etc which are not possible. Since peek and stare are non-final states I can easily imagine that OpenSSL library negotiates ciphers which the options would otherwise prohibit. Then when the options get applied to the context it find itself using an algorithm which does not exist. The context SSL_CTX objects are bases to create the SSL objects which are responsible for the negotiation with the other side (server in this case). The SSL created, inherits the options from CTXa nd we are adding our options to SSL object. The SSL library will use these options to build client hello message, parse server hello message and select algorithms/ciphers and other features to establish SSL connection. In my patch the options applied to the squid client SSL objects immediately after created, in the case of bump-server-first, or bump-client-first. In the cases of peek or stare we are not setting any options. This is because we are sending a hello message which is the same or similar with the client hello message, so we can not apply options. Else the peek or stare will fail... What I means is the code flow is roughly like this yes? 1) bump 2) splice 3) peek then bump 4) stare then bump 5) peek then splice 6) stare then splice In which of those cases are the options set? all cases ending in bump or splice. The important factor here is the bumping step. in bump case (1,3,4) - if the decision is to bump in bumpStep1 or bumpStep2 then the squid SSL client options are set. - If the decision for bumping taken in bumpStep3, the the squid SSL client options are NOT set. in splice case (2,5 or 6) : - if we splice on bumpStep1 or on bumpStep2, then we are not using squid SSL client code at all, so the options does not play any role on this case. - If we splice on bumpStep3 we have use squid SSL client, but in this case the options are not set. After the bumpStep2 completed we have received the client hello message, but we do not sent any response (server hello). At the same time we are starting to initiate the connection to the SSL server. This is mean that we are going to set SSL client hello message which is depends on SSL client code. So: - If we know that we will going to bump the connection, we can safely set SSL client options. This is because the squid SSL client will initiate a normal SSL connection. - If we are going to stare, or peek then the client hello message we are going to sent must be similar to the client-to-squid SSL hello message. In this case we can not control SSL features using options, else the SSL negotiation will fail. So you're saying the src/ssl/PeerConnector.cc else-condition never gets run after a peek and/or stare ? Do you mean the "if (csd->sslBumpMode == Ssl::bumpPeek || csd->sslBumpMode == Ssl::bumpStare)" ? I mean the: } else { +// Set client SSL options +SSL_set_options(ssl, ::Config.ssl_client.parsedOptions); + Yes the "else" never gets run when peek or stare mode selected in bumpStep2 bumping step. Then please add a Must(step <= 2) check at the start of that else condition right before setting the SSL client options. If that works properly I am happy for this to go in. Requires a code like the following: Must(csd->sslServerBump()->step<=Ssl::bumpStep2); Specifically: Must( !csd->sslServerBump() || csd->sslServerBump()->step <= Ssl::bumpStep2 ); This is will not work. In client-first bumping mode or in server-first bumping mode where we are not applying the peek-and-splice procedure the step is not updated. Which would make step 0 or 1 for client-first right? that is fine. For server-first it does need updating at the point the server is given data. A jump right to step 3, or even a new "sslBumpStepServerFirst" value at the end of the enum. Exactly. But why do you beleive this Must is needed? Specially inside "else" is completely w
Re: [squid-dev] [PATCH] sslproxy_options in peek-and-splice mode
On 13/02/2015 3:34 a.m., Tsantilas Christos wrote: > On 02/12/2015 01:48 PM, Amos Jeffries wrote: >> On 12/02/2015 11:31 p.m., Tsantilas Christos wrote: >>> On 02/11/2015 09:48 PM, Amos Jeffries wrote: On 12/02/2015 12:45 a.m., Tsantilas Christos wrote: > On 02/11/2015 01:54 AM, Amos Jeffries wrote: >> On 9/02/2015 6:43 a.m., Tsantilas Christos wrote: >>> Bug description: >>> >>> - Squid sslproxy_options deny the use of TLSv1_2 SSL protocol: >>> sslproxy_options NO_TLSv1_2 >>> - Squid uses peek mode for bumped connections. >>> - Web client sends an TLSv1_2 hello message and squid in peek >>> mode, >>> forwards the client hello message to server >>> - Web server respond with an TLSv1_2 hello message >>> - Squid while parsing server hello message aborts with an error >>> because sslproxy_options deny the use ot TLSv1_2 protocol. >>> >>> This patch fixes squid to ignore sslproxy_options in peek or stare >>> bumping mode. >> >> As I understand it the action of applying the options to the context >> removes from the context cipher references etc which are not >> possible. >> >> Since peek and stare are non-final states I can easily imagine that >> OpenSSL library negotiates ciphers which the options would otherwise >> prohibit. Then when the options get applied to the context it find >> itself using an algorithm which does not exist. > > The context SSL_CTX objects are bases to create the SSL objects which > are responsible for the negotiation with the other side (server in > this > case). > The SSL created, inherits the options from CTXa nd we are adding our > options to SSL object. > The SSL library will use these options to build client hello message, > parse server hello message and select algorithms/ciphers and other > features to establish SSL connection. > > In my patch the options applied to the squid client SSL objects > immediately after created, in the case of bump-server-first, or > bump-client-first. > > In the cases of peek or stare we are not setting any options. This is > because we are sending a hello message which is the same or similar > with > the client hello message, so we can not apply options. Else the > peek or > stare will fail... > What I means is the code flow is roughly like this yes? 1) bump 2) splice 3) peek then bump 4) stare then bump 5) peek then splice 6) stare then splice In which of those cases are the options set? all cases ending in bump or splice. >>> >>> The important factor here is the bumping step. >>> in bump case (1,3,4) >>> - if the decision is to bump in bumpStep1 or bumpStep2 then the squid >>> SSL client options are set. >>> - If the decision for bumping taken in bumpStep3, the the squid SSL >>> client options are NOT set. >>> >>> in splice case (2,5 or 6) : >>> - if we splice on bumpStep1 or on bumpStep2, then we are not using >>> squid SSL client code at all, so the options does not play any role on >>> this case. >>> - If we splice on bumpStep3 we have use squid SSL client, but in this >>> case the options are not set. >>> >>> >>> After the bumpStep2 completed we have received the client hello message, >>> but we do not sent any response (server hello). At the same time we are >>> starting to initiate the connection to the SSL server. This is mean that >>> we are going to set SSL client hello message which is depends on SSL >>> client code. So: >>>- If we know that we will going to bump the connection, we can safely >>> set SSL client options. This is because the squid SSL client will >>> initiate a normal SSL connection. >>>- If we are going to stare, or peek then the client hello message we >>> are going to sent must be similar to the client-to-squid SSL hello >>> message. In this case we can not control SSL features using options, >>> else the SSL negotiation will fail. >> >> So you're saying the src/ssl/PeerConnector.cc else-condition never gets >> run after a peek and/or stare ? > > Do you mean the "if (csd->sslBumpMode == Ssl::bumpPeek || > csd->sslBumpMode == Ssl::bumpStare)" ? I mean the: } else { +// Set client SSL options +SSL_set_options(ssl, ::Config.ssl_client.parsedOptions); + > > Yes the "else" never gets run when peek or stare mode selected in > bumpStep2 bumping step. > > > >> >> Then please add a Must(step <= 2) check at the start of that else >> condition right before setting the SSL client options. If that works >> properly I am happy for this to go in. > > Requires a code like the following: > Must(csd->sslServerBump()->step<=Ssl::bumpStep2); Specifically: Must( !csd->sslServerBump() || csd->sslServerBump()->step <= Ssl::bumpStep2 ); > > This is will not work. In client-first bumping
Re: [squid-dev] [PATCH] sslproxy_options in peek-and-splice mode
On 02/12/2015 01:48 PM, Amos Jeffries wrote: On 12/02/2015 11:31 p.m., Tsantilas Christos wrote: On 02/11/2015 09:48 PM, Amos Jeffries wrote: On 12/02/2015 12:45 a.m., Tsantilas Christos wrote: On 02/11/2015 01:54 AM, Amos Jeffries wrote: On 9/02/2015 6:43 a.m., Tsantilas Christos wrote: Bug description: - Squid sslproxy_options deny the use of TLSv1_2 SSL protocol: sslproxy_options NO_TLSv1_2 - Squid uses peek mode for bumped connections. - Web client sends an TLSv1_2 hello message and squid in peek mode, forwards the client hello message to server - Web server respond with an TLSv1_2 hello message - Squid while parsing server hello message aborts with an error because sslproxy_options deny the use ot TLSv1_2 protocol. This patch fixes squid to ignore sslproxy_options in peek or stare bumping mode. As I understand it the action of applying the options to the context removes from the context cipher references etc which are not possible. Since peek and stare are non-final states I can easily imagine that OpenSSL library negotiates ciphers which the options would otherwise prohibit. Then when the options get applied to the context it find itself using an algorithm which does not exist. The context SSL_CTX objects are bases to create the SSL objects which are responsible for the negotiation with the other side (server in this case). The SSL created, inherits the options from CTXa nd we are adding our options to SSL object. The SSL library will use these options to build client hello message, parse server hello message and select algorithms/ciphers and other features to establish SSL connection. In my patch the options applied to the squid client SSL objects immediately after created, in the case of bump-server-first, or bump-client-first. In the cases of peek or stare we are not setting any options. This is because we are sending a hello message which is the same or similar with the client hello message, so we can not apply options. Else the peek or stare will fail... What I means is the code flow is roughly like this yes? 1) bump 2) splice 3) peek then bump 4) stare then bump 5) peek then splice 6) stare then splice In which of those cases are the options set? all cases ending in bump or splice. The important factor here is the bumping step. in bump case (1,3,4) - if the decision is to bump in bumpStep1 or bumpStep2 then the squid SSL client options are set. - If the decision for bumping taken in bumpStep3, the the squid SSL client options are NOT set. in splice case (2,5 or 6) : - if we splice on bumpStep1 or on bumpStep2, then we are not using squid SSL client code at all, so the options does not play any role on this case. - If we splice on bumpStep3 we have use squid SSL client, but in this case the options are not set. After the bumpStep2 completed we have received the client hello message, but we do not sent any response (server hello). At the same time we are starting to initiate the connection to the SSL server. This is mean that we are going to set SSL client hello message which is depends on SSL client code. So: - If we know that we will going to bump the connection, we can safely set SSL client options. This is because the squid SSL client will initiate a normal SSL connection. - If we are going to stare, or peek then the client hello message we are going to sent must be similar to the client-to-squid SSL hello message. In this case we can not control SSL features using options, else the SSL negotiation will fail. So you're saying the src/ssl/PeerConnector.cc else-condition never gets run after a peek and/or stare ? Do you mean the "if (csd->sslBumpMode == Ssl::bumpPeek || csd->sslBumpMode == Ssl::bumpStare)" ? Yes the "else" never gets run when peek or stare mode selected in bumpStep2 bumping step. Then please add a Must(step <= 2) check at the start of that else condition right before setting the SSL client options. If that works properly I am happy for this to go in. Requires a code like the following: Must(csd->sslServerBump()->step<=Ssl::bumpStep2); This is will not work. In client-first bumping mode or in server-first bumping mode where we are not applying the peek-and-splice procedure the step is not updated. Also my sense is that in client-first bumping mode the csd->sslServerBump() is NULL. NP: the above explanation may be worth adding to the commit message as an explanation for what the line "This patch fixes squid to ignore sslproxy_options in peek or stare bumping mode" actually means. OK, I will try to add some explanations in commit message. Amos ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
Re: [squid-dev] [PATCH] sslproxy_options in peek-and-splice mode
On 12/02/2015 11:31 p.m., Tsantilas Christos wrote: > On 02/11/2015 09:48 PM, Amos Jeffries wrote: >> On 12/02/2015 12:45 a.m., Tsantilas Christos wrote: >>> On 02/11/2015 01:54 AM, Amos Jeffries wrote: On 9/02/2015 6:43 a.m., Tsantilas Christos wrote: > Bug description: > > - Squid sslproxy_options deny the use of TLSv1_2 SSL protocol: > sslproxy_options NO_TLSv1_2 > - Squid uses peek mode for bumped connections. > - Web client sends an TLSv1_2 hello message and squid in peek > mode, > forwards the client hello message to server > - Web server respond with an TLSv1_2 hello message > - Squid while parsing server hello message aborts with an error > because sslproxy_options deny the use ot TLSv1_2 protocol. > > This patch fixes squid to ignore sslproxy_options in peek or stare > bumping mode. As I understand it the action of applying the options to the context removes from the context cipher references etc which are not possible. Since peek and stare are non-final states I can easily imagine that OpenSSL library negotiates ciphers which the options would otherwise prohibit. Then when the options get applied to the context it find itself using an algorithm which does not exist. >>> >>> The context SSL_CTX objects are bases to create the SSL objects which >>> are responsible for the negotiation with the other side (server in this >>> case). >>> The SSL created, inherits the options from CTXa nd we are adding our >>> options to SSL object. >>> The SSL library will use these options to build client hello message, >>> parse server hello message and select algorithms/ciphers and other >>> features to establish SSL connection. >>> >>> In my patch the options applied to the squid client SSL objects >>> immediately after created, in the case of bump-server-first, or >>> bump-client-first. >>> >>> In the cases of peek or stare we are not setting any options. This is >>> because we are sending a hello message which is the same or similar with >>> the client hello message, so we can not apply options. Else the peek or >>> stare will fail... >>> >> >> What I means is the code flow is roughly like this yes? >> >> 1) bump >> 2) splice >> 3) peek then bump >> 4) stare then bump >> 5) peek then splice >> 6) stare then splice >> >> In which of those cases are the options set? >> all cases ending in bump or splice. > > The important factor here is the bumping step. > in bump case (1,3,4) > - if the decision is to bump in bumpStep1 or bumpStep2 then the squid > SSL client options are set. > - If the decision for bumping taken in bumpStep3, the the squid SSL > client options are NOT set. > > in splice case (2,5 or 6) : > - if we splice on bumpStep1 or on bumpStep2, then we are not using > squid SSL client code at all, so the options does not play any role on > this case. > - If we splice on bumpStep3 we have use squid SSL client, but in this > case the options are not set. > > > After the bumpStep2 completed we have received the client hello message, > but we do not sent any response (server hello). At the same time we are > starting to initiate the connection to the SSL server. This is mean that > we are going to set SSL client hello message which is depends on SSL > client code. So: > - If we know that we will going to bump the connection, we can safely > set SSL client options. This is because the squid SSL client will > initiate a normal SSL connection. > - If we are going to stare, or peek then the client hello message we > are going to sent must be similar to the client-to-squid SSL hello > message. In this case we can not control SSL features using options, > else the SSL negotiation will fail. So you're saying the src/ssl/PeerConnector.cc else-condition never gets run after a peek and/or stare ? Then please add a Must(step <= 2) check at the start of that else condition right before setting the SSL client options. If that works properly I am happy for this to go in. NP: the above explanation may be worth adding to the commit message as an explanation for what the line "This patch fixes squid to ignore sslproxy_options in peek or stare bumping mode" actually means. Amos ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
Re: [squid-dev] [PATCH] sslproxy_options in peek-and-splice mode
On 02/11/2015 09:48 PM, Amos Jeffries wrote: On 12/02/2015 12:45 a.m., Tsantilas Christos wrote: On 02/11/2015 01:54 AM, Amos Jeffries wrote: On 9/02/2015 6:43 a.m., Tsantilas Christos wrote: Bug description: - Squid sslproxy_options deny the use of TLSv1_2 SSL protocol: sslproxy_options NO_TLSv1_2 - Squid uses peek mode for bumped connections. - Web client sends an TLSv1_2 hello message and squid in peek mode, forwards the client hello message to server - Web server respond with an TLSv1_2 hello message - Squid while parsing server hello message aborts with an error because sslproxy_options deny the use ot TLSv1_2 protocol. This patch fixes squid to ignore sslproxy_options in peek or stare bumping mode. As I understand it the action of applying the options to the context removes from the context cipher references etc which are not possible. Since peek and stare are non-final states I can easily imagine that OpenSSL library negotiates ciphers which the options would otherwise prohibit. Then when the options get applied to the context it find itself using an algorithm which does not exist. The context SSL_CTX objects are bases to create the SSL objects which are responsible for the negotiation with the other side (server in this case). The SSL created, inherits the options from CTXa nd we are adding our options to SSL object. The SSL library will use these options to build client hello message, parse server hello message and select algorithms/ciphers and other features to establish SSL connection. In my patch the options applied to the squid client SSL objects immediately after created, in the case of bump-server-first, or bump-client-first. In the cases of peek or stare we are not setting any options. This is because we are sending a hello message which is the same or similar with the client hello message, so we can not apply options. Else the peek or stare will fail... What I means is the code flow is roughly like this yes? 1) bump 2) splice 3) peek then bump 4) stare then bump 5) peek then splice 6) stare then splice In which of those cases are the options set? all cases ending in bump or splice. The important factor here is the bumping step. in bump case (1,3,4) - if the decision is to bump in bumpStep1 or bumpStep2 then the squid SSL client options are set. - If the decision for bumping taken in bumpStep3, the the squid SSL client options are NOT set. in splice case (2,5 or 6) : - if we splice on bumpStep1 or on bumpStep2, then we are not using squid SSL client code at all, so the options does not play any role on this case. - If we splice on bumpStep3 we have use squid SSL client, but in this case the options are not set. After the bumpStep2 completed we have received the client hello message, but we do not sent any response (server hello). At the same time we are starting to initiate the connection to the SSL server. This is mean that we are going to set SSL client hello message which is depends on SSL client code. So: - If we know that we will going to bump the connection, we can safely set SSL client options. This is because the squid SSL client will initiate a normal SSL connection. - If we are going to stare, or peek then the client hello message we are going to sent must be similar to the client-to-squid SSL hello message. In this case we can not control SSL features using options, else the SSL negotiation will fail. Also, for this bug to have occured at all means the server SSL_CTX is being actively used during the peek/stare steps. The SSL_CTX is an object which holds predefined settings and options for SSL objects. This patch sets the options for the SSL object not the SSL_CTX options. So what can possibly go wrong by changing the CTX cipher sets halfway through case 3, 4, 5, 6 ? We are not changing anything in SSL_CTX object This is has as result that we can not control the ssl behaviour in peek or stare mode. But it is not easy to do anything else... Maybe we can add 1-2 new configurations parameter which control the behaviour. But this is a different project... I agree we should do the not-setting-options. What I'm having issues with is how it appears that they are set later - which could be just adding a different problem. Amos ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
Re: [squid-dev] [PATCH] sslproxy_options in peek-and-splice mode
On 12/02/2015 12:45 a.m., Tsantilas Christos wrote: > On 02/11/2015 01:54 AM, Amos Jeffries wrote: >> On 9/02/2015 6:43 a.m., Tsantilas Christos wrote: >>> Bug description: >>> >>>- Squid sslproxy_options deny the use of TLSv1_2 SSL protocol: >>> sslproxy_options NO_TLSv1_2 >>>- Squid uses peek mode for bumped connections. >>>- Web client sends an TLSv1_2 hello message and squid in peek mode, >>> forwards the client hello message to server >>>- Web server respond with an TLSv1_2 hello message >>>- Squid while parsing server hello message aborts with an error >>> because sslproxy_options deny the use ot TLSv1_2 protocol. >>> >>> This patch fixes squid to ignore sslproxy_options in peek or stare >>> bumping mode. >> >> As I understand it the action of applying the options to the context >> removes from the context cipher references etc which are not possible. >> >> Since peek and stare are non-final states I can easily imagine that >> OpenSSL library negotiates ciphers which the options would otherwise >> prohibit. Then when the options get applied to the context it find >> itself using an algorithm which does not exist. > > The context SSL_CTX objects are bases to create the SSL objects which > are responsible for the negotiation with the other side (server in this > case). > The SSL created, inherits the options from CTXa nd we are adding our > options to SSL object. > The SSL library will use these options to build client hello message, > parse server hello message and select algorithms/ciphers and other > features to establish SSL connection. > > In my patch the options applied to the squid client SSL objects > immediately after created, in the case of bump-server-first, or > bump-client-first. > > In the cases of peek or stare we are not setting any options. This is > because we are sending a hello message which is the same or similar with > the client hello message, so we can not apply options. Else the peek or > stare will fail... > What I means is the code flow is roughly like this yes? 1) bump 2) splice 3) peek then bump 4) stare then bump 5) peek then splice 6) stare then splice In which of those cases are the options set? all cases ending in bump or splice. Also, for this bug to have occured at all means the server SSL_CTX is being actively used during the peek/stare steps. So what can possibly go wrong by changing the CTX cipher sets halfway through case 3, 4, 5, 6 ? > This is has as result that we can not control the ssl behaviour in peek > or stare mode. But it is not easy to do anything else... > Maybe we can add 1-2 new configurations parameter which control the > behaviour. But this is a different project... I agree we should do the not-setting-options. What I'm having issues with is how it appears that they are set later - which could be just adding a different problem. Amos ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
Re: [squid-dev] [PATCH] sslproxy_options in peek-and-splice mode
On 02/11/2015 01:54 AM, Amos Jeffries wrote: On 9/02/2015 6:43 a.m., Tsantilas Christos wrote: Bug description: - Squid sslproxy_options deny the use of TLSv1_2 SSL protocol: sslproxy_options NO_TLSv1_2 - Squid uses peek mode for bumped connections. - Web client sends an TLSv1_2 hello message and squid in peek mode, forwards the client hello message to server - Web server respond with an TLSv1_2 hello message - Squid while parsing server hello message aborts with an error because sslproxy_options deny the use ot TLSv1_2 protocol. This patch fixes squid to ignore sslproxy_options in peek or stare bumping mode. As I understand it the action of applying the options to the context removes from the context cipher references etc which are not possible. Since peek and stare are non-final states I can easily imagine that OpenSSL library negotiates ciphers which the options would otherwise prohibit. Then when the options get applied to the context it find itself using an algorithm which does not exist. The context SSL_CTX objects are bases to create the SSL objects which are responsible for the negotiation with the other side (server in this case). The SSL created, inherits the options from CTXa nd we are adding our options to SSL object. The SSL library will use these options to build client hello message, parse server hello message and select algorithms/ciphers and other features to establish SSL connection. In my patch the options applied to the squid client SSL objects immediately after created, in the case of bump-server-first, or bump-client-first. In the cases of peek or stare we are not setting any options. This is because we are sending a hello message which is the same or similar with the client hello message, so we can not apply options. Else the peek or stare will fail... This is has as result that we can not control the ssl behaviour in peek or stare mode. But it is not easy to do anything else... Maybe we can add 1-2 new configurations parameter which control the behaviour. But this is a different project... Regards, Christos So what happens during the final state in that type of event? Amos ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
Re: [squid-dev] [PATCH] sslproxy_options in peek-and-splice mode
On 9/02/2015 6:43 a.m., Tsantilas Christos wrote: > Bug description: > > - Squid sslproxy_options deny the use of TLSv1_2 SSL protocol: >sslproxy_options NO_TLSv1_2 > - Squid uses peek mode for bumped connections. > - Web client sends an TLSv1_2 hello message and squid in peek mode, > forwards the client hello message to server > - Web server respond with an TLSv1_2 hello message > - Squid while parsing server hello message aborts with an error > because sslproxy_options deny the use ot TLSv1_2 protocol. > > This patch fixes squid to ignore sslproxy_options in peek or stare > bumping mode. As I understand it the action of applying the options to the context removes from the context cipher references etc which are not possible. Since peek and stare are non-final states I can easily imagine that OpenSSL library negotiates ciphers which the options would otherwise prohibit. Then when the options get applied to the context it find itself using an algorithm which does not exist. So what happens during the final state in that type of event? Amos ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
[squid-dev] [PATCH] sslproxy_options in peek-and-splice mode
Bug description: - Squid sslproxy_options deny the use of TLSv1_2 SSL protocol: sslproxy_options NO_TLSv1_2 - Squid uses peek mode for bumped connections. - Web client sends an TLSv1_2 hello message and squid in peek mode, forwards the client hello message to server - Web server respond with an TLSv1_2 hello message - Squid while parsing server hello message aborts with an error because sslproxy_options deny the use ot TLSv1_2 protocol. This patch fixes squid to ignore sslproxy_options in peek or stare bumping mode. This is a Measurement Factory project sslproxy_options in peek-and-splice mode Problem description: - Squid sslproxy_options deny the use of TLSv1_2 SSL protocol: sslproxy_options NO_TLSv1_2 - Squid uses peek mode for bumped connections. - Web client sends an TLSv1_2 hello message and squid in peek mode, forwards the client hello message to server - Web server respond with an TLSv1_2 hello message - Squid while parsing server hello message aborts with an error because sslproxy_options deny the use ot TLSv1_2 protocol. This patch fixes squid to ignore sslproxy_options in peek or stare bumping mode. This is a Measurement Factory project === modified file 'src/SquidConfig.h' --- src/SquidConfig.h 2015-02-02 16:20:11 + +++ src/SquidConfig.h 2015-02-06 19:09:37 + @@ -487,40 +487,41 @@ wordlist *ext_methods; struct { int high_rptm; int high_pf; size_t high_memory; } warnings; char *store_dir_select_algorithm; int sleep_after_fork; /* microseconds */ time_t minimum_expiry_time; /* seconds */ external_acl *externalAclHelperList; #if USE_OPENSSL struct { char *cert; char *key; int version; char *options; +long parsedOptions; char *cipher; char *cafile; char *capath; char *crlfile; char *flags; acl_access *cert_error; SSL_CTX *sslContext; sslproxy_cert_sign *cert_sign; sslproxy_cert_adapt *cert_adapt; } ssl_client; #endif char *accept_filter; int umask; int max_filedescriptors; int workers; CpuAffinityMap *cpuAffinityMap; #if USE_LOADABLE_MODULES wordlist *loadable_module_names; === modified file 'src/cache_cf.cc' --- src/cache_cf.cc 2015-02-02 20:02:55 + +++ src/cache_cf.cc 2015-02-06 19:09:37 + @@ -869,41 +869,44 @@ Config2.effectiveGroupID = getegid(); } if (NULL != Config.effectiveGroup) { struct group *grp = getgrnam(Config.effectiveGroup); if (NULL == grp) { fatalf("getgrnam failed to find groupid for effective group '%s'", Config.effectiveGroup); return; } Config2.effectiveGroupID = grp->gr_gid; } #if USE_OPENSSL debugs(3, DBG_IMPORTANT, "Initializing https proxy context"); -Config.ssl_client.sslContext = sslCreateClientContext(Config.ssl_client.cert, Config.ssl_client.key, Config.ssl_client.version, Config.ssl_client.cipher, Config.ssl_client.options, Config.ssl_client.flags, Config.ssl_client.cafile, Config.ssl_client.capath, Config.ssl_client.crlfile); +Config.ssl_client.sslContext = sslCreateClientContext(Config.ssl_client.cert, Config.ssl_client.key, Config.ssl_client.version, Config.ssl_client.cipher, NULL, Config.ssl_client.flags, Config.ssl_client.cafile, Config.ssl_client.capath, Config.ssl_client.crlfile); +// Pre-parse SSL client options to be applied when the client SSL objects created. +// Options must not used in the case of peek or stare bump mode. +Config.ssl_client.parsedOptions = Ssl::parse_options(::Config.ssl_client.options); for (CachePeer *p = Config.peers; p != NULL; p = p->next) { if (p->use_ssl) { debugs(3, DBG_IMPORTANT, "Initializing cache_peer " << p->name << " SSL context"); p->sslContext = sslCreateClientContext(p->sslcert, p->sslkey, p->sslversion, p->sslcipher, p->ssloptions, p->sslflags, p->sslcafile, p->sslcapath, p->sslcrlfile); } } for (AnyP::PortCfgPointer s = HttpPortList; s != NULL; s = s->next) { if (!s->flags.tunnelSslBumping) continue; debugs(3, DBG_IMPORTANT, "Initializing http_port " << s->s << " SSL context"); s->configureSslServerContext(); } for (AnyP::PortCfgPointer s = HttpsPortList; s != NULL; s = s->next) { debugs(3, DBG_IMPORTANT, "Initializing https_port " << s->s << " SSL context"); s->configureSslServerContext(); } === modified file 'src/ssl/PeerConnector.cc' --- src/ssl/PeerConnector.cc 2015-01-13 07:25:36 + +++ src/ssl/PeerConnector.cc 2015-01-29 17:05:32 + @@ -155,40 +155,43 @@ const Ssl::Bio::sslFeatures &features = clnBio->getFeatures(); if (features.sslVersion != -1) { features.applyToSSL(ssl);