LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Server
User Name
Password
Linux - Server This forum is for the discussion of Linux Software used in a server related context.

Notices

Reply
 
Search this Thread
Old 09-06-2010, 06:27 AM   #1
juventus
LQ Newbie
 
Registered: Sep 2006
Posts: 2

Rep: Reputation: 0
SSL renegotiation failing even after enabling SSLInsecureRenegotiation directive.


As would be clear from the post header, i am trying for an insecure SSL renegotiaion as my SSL client does not have support for the latest TLS renegotiation vulnerability (CVE-2009-3555).

My server configuration :
server: Apache/2.2.16 (Unix) mod_ssl/2.2.16 OpenSSL/1.0.0a on Ubuntu 10.04.1 LTS

The problem is my handshake goes through successfully, but in application data stage client initiates the renegotiation upon which i get thrown an error and the connection terminates. I did enable SSLInsecureRenegotiation directive, but the error persists.

Error as received on the client side ( as interpreted by the client) is EOF (does not convey much). But the same client when connected to the earlier version of APACHE - 2.0.47 works pretty fine.

Error on server side corresponding to my client request in error.log represents :
[Fri Sep 03 16:19:16 2010] [error] [client 10.225.171.98] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /index.html
[Fri Sep 03 16:19:38 2010] [error] [client 10.225.171.98] rejecting client initiated renegotiation

SSL conf file (vhost configuration in https-ssl.conf ) :

<VirtualHost 10.225.209.115:543>

SSLInsecureRenegotiation on [I even tried placing it globally, but with no +ve outcome]
DocumentRoot "/usr/local/apache2/htdocs"
ServerName httpsmtpssl.test.intra
ServerAdmin you@example.com
ErrorLog "/usr/local/apache2/logs/error_log"
TransferLog "/usr/local/apache2/logs/access_log"

SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

SSLCertificateFile "/usr/local/apache2/conf/ssl.crt/server.crt"
SSLCertificateKeyFile "/usr/local/apache2/conf/ssl.key/NO-PASS-PHRASE"

<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory "/usr/local/apache2/cgi-bin">
SSLOptions +StdEnvVars
</Directory>

BrowserMatch ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0

CustomLog "/usr/local/apache2/logs/ssl_request_log" \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

</VirtualHost>

Can you guys, help me with this ?
Am i missing something on the server config part or not using the SSLInsecureRenegotiation directive correctly ?

Hope to get some pointers,
Gaurav
 
Old 09-06-2010, 07:51 AM   #2
sag47
Senior Member
 
Registered: Sep 2009
Location: Philly, PA
Distribution: Kubuntu x64, RHEL, Fedora Core, FreeBSD, Windows x64
Posts: 1,465
Blog Entries: 35

Rep: Reputation: 363Reputation: 363Reputation: 363Reputation: 363
First, please make use of the post styles such as headings and code tags to organize your code when you provide so much information. It took me about 20 mins to sift through the bulk of information and even begin to decipher what you were trying to accomplish. You'll get a more positive, correct, or prompt response from the community and possibly your problem solved.

On to the problem. I don't know much about this so bear with me because I'm just going to be applying problem solving to this issue. Basically, what I gather from your information is that when someone visits your website with http://mywebsite you want them automatically redirected to https://mywebsite; Am I correct?

Does your website act normally when you visit it directly with https://mywebsite?

--------------------------------------------------

Quote:
[Fri Sep 03 16:19:16 2010] [error] [client 10.225.171.98] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /index.html
This apparently does not affect the operation of your server. This is a requirement of HTTP 1.1 but your client didn't do that. Not a big deal. Here's more information about it.
Quote:
Code:
RFC 2616                        HTTP/1.1                       June 1999


14.23 Host

   The Host request-header field specifies the Internet host and port
   number of the resource being requested, as obtained from the original
   URI given by the user or referring resource (generally an HTTP URL,
   as described in section 3.2.2). The Host field value MUST represent
   the naming authority of the origin server or gateway given by the
   original URL. This allows the origin server or gateway to
   differentiate between internally-ambiguous URLs, such as the root "/"
   URL of a server for multiple host names on a single IP address.

       Host = "Host" ":" host [ ":" port ] ; Section 3.2.2

   A "host" without any trailing port information implies the default
   port for the service requested (e.g., "80" for an HTTP URL). For
   example, a request on the origin server for
   <http://www.w3.org/pub/WWW/> would properly include:

       GET /pub/WWW/ HTTP/1.1
       Host: www.w3.org

   A client MUST include a Host header field in all HTTP/1.1 request
   messages . If the requested URI does not include an Internet host
   name for the service being requested, then the Host header field MUST
   be given with an empty value. An HTTP/1.1 proxy MUST ensure that any
   request message it forwards does contain an appropriate Host header
   field that identifies the service being requested by the proxy. All
   Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request)
   status code to any HTTP/1.1 request message which lacks a Host header
   field.

   See sections 5.2 and 19.6.1.1 for other requirements relating to
   Host.



5.3 Request Header Fields

   The request-header fields allow the client to pass additional
   information about the request, and about the client itself, to the
   server. These fields act as request modifiers, with semantics
   equivalent to the parameters on a programming language method
   invocation.

       request-header = Accept                   ; Section 14.1
                      | Accept-Charset           ; Section 14.2
                      | Accept-Encoding          ; Section 14.3
                      | Accept-Language          ; Section 14.4
                      | Authorization            ; Section 14.8
                      | Expect                   ; Section 14.20
                      | From                     ; Section 14.22
                      | Host                     ; Section 14.23
                      | If-Match                 ; Section 14.24
                      | If-Modified-Since        ; Section 14.25
                      | If-None-Match            ; Section 14.26
                      | If-Range                 ; Section 14.27
                      | If-Unmodified-Since      ; Section 14.28
                      | Max-Forwards             ; Section 14.31
                      | Proxy-Authorization      ; Section 14.34
                      | Range                    ; Section 14.35
                      | Referer                  ; Section 14.36
                      | TE                       ; Section 14.39
                      | User-Agent               ; Section 14.43

   Request-header field names can be extended reliably only in
   combination with a change in the protocol version. However, new or
   experimental header fields MAY be given the semantics of request-
   header fields if all parties in the communication recognize them to
   be request-header fields. Unrecognized header fields are treated as
   entity-header fields.



19.6.1.1 Changes to Simplify Multi-homed Web Servers and Conserve IP
         Addresses

   The requirements that clients and servers support the Host request-
   header, report an error if the Host request-header (section 14.23) is
   missing from an HTTP/1.1 request, and accept absolute URIs (section
   5.1.2) are among the most important changes defined by this
   specification.

   Older HTTP/1.0 clients assumed a one-to-one relationship of IP
   addresses and servers; there was no other established mechanism for
   distinguishing the intended server of a request than the IP address
   to which that request was directed. The changes outlined above will
   allow the Internet, once older HTTP clients are no longer common, to
   support multiple Web sites from a single IP address, greatly
   simplifying large operational Web servers, where allocation of many
   IP addresses to a single host has created serious problems. The
   Internet will also be able to recover the IP addresses that have been
   allocated for the sole purpose of allowing special-purpose domain
   names to be used in root-level HTTP URLs. Given the rate of growth of
   the Web, and the number of servers already deployed, it is extremely
   important that all implementations of HTTP (including updates to
   existing HTTP/1.0 applications) correctly implement these
   requirements:

      - Both clients and servers MUST support the Host request-header.

      - A client that sends an HTTP/1.1 request MUST send a Host header.

      - Servers MUST report a 400 (Bad Request) error if an HTTP/1.1
        request does not include a Host request-header.

      - Servers MUST accept absolute URIs.
--------------------------------------------------


Can you try adding the option SSLVerifyClient optional to your virtual host section? Does this change the result? What is the error output now?

I'll continue researching the problem but I'm still not entirely sure what you're trying to accomplish.

Some possible useful links:
Patch pertaining to renegotiation containing your error message (which does not allow client initiated re-negotiations)
SSL_SECURE_RENEG Environment Variable
SSLInsecureRenegotiation Directive
Some interesting points on SSL Reneg

Last edited by sag47; 09-06-2010 at 07:55 AM.
 
Old 09-09-2010, 01:47 AM   #3
juventus
LQ Newbie
 
Registered: Sep 2006
Posts: 2

Original Poster
Rep: Reputation: 0
Thanks for the heads up !
And will sure make use of the post styles available.
Quote:
Does your website act normally when you visit it directly with https://mywebsite?
Yup, it does.
At this point let me elaborate my use case here.
My TLS client makes a secure connection to one of the local https servers on my LAN and in the App Data stage asks for renegotiation. With older servers it used to work but with newer Apache (TLS renegotiation venerability patched) server it did not. Then looking further i found the "SSLInsecureRenegotiation" directory, which is, still, not solving my purpose.
Quote:
Quote:
[Fri Sep 03 16:19:16 2010] [error] [client 10.225.171.98] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /index.html
This apparently does not affect the operation of your server. This is a requirement of HTTP 1.1 but your client didn't do that. Not a big deal. Here's more information about it.
Agreed, and this does not bother me much, as of now.
Quote:
Can you try adding the option SSLVerifyClient optional to your virtual host section? Does this change the result? What is the error output now?
I did, but without much avail;Same error code on server as before !

Btw, i got reply from openssl-dev forum, stating :
Quote:
On Mon, 6 Sep 2010 15:12:34 +0530 gaurav jha wrote:

> The problem is my handshake goes through successfully, but in
> application data stage client initiates the renegotiation upon which
> i get thrown an error and the connection terminates. I did enable
> SSLInsecureRenegotiation directive, but the error persists.

SSLInsecureRenegotiation setting and RFC 5746 support on the client
side do not matter in your case, current mod_ssl always rejects client
initiated renegotiation.

th.
So, there it is, current mod_ssl does not support client initiated renegotiation.
Why ? i am still not sure about it !
Where as apache documentation says this regarding the SSLInsecureRenegotiation directive :
Quote:
If mod_ssl is linked against OpenSSL version 0.9.8m or later, by default renegotiation is only supported with clients supporting the new protocol extension. If this directive is enabled, renegotiation will be allowed with old (unpatched) clients, albeit insecurely.
I wonder, renegotiation implies both client as well as server initiated renegotiation !

As of now, roll backing to a lower server version(may be httpd-2.2.14) without this security patch should serve my cause.

Thanks a lot,
Gaurav
 
Old 09-09-2010, 02:58 AM   #4
sag47
Senior Member
 
Registered: Sep 2009
Location: Philly, PA
Distribution: Kubuntu x64, RHEL, Fedora Core, FreeBSD, Windows x64
Posts: 1,465
Blog Entries: 35

Rep: Reputation: 363Reputation: 363Reputation: 363Reputation: 363
Quote:
Originally Posted by juventus View Post
I wonder, renegotiation implies both client as well as server initiated renegotiation !

As of now, roll backing to a lower server version(may be httpd-2.2.14) without this security patch should serve my cause.

Thanks a lot,
Gaurav
I saw that it only allows client initiated from the source. Aparently it only applies to server side initiated renegotiation.

Code:
+/*
+ * This callback function is executed while OpenSSL processes the SSL
+ * handshake and does SSL record layer stuff.  It's used to trap
+ * client-initiated renegotiations, and for dumping everything to the
+ * log.
+ */
+void ssl_callback_Info(MODSSL_INFO_CB_ARG_TYPE ssl, int where, int rc)
+{
+    conn_rec *c;
+    server_rec *s;
+    SSLSrvConfigRec *sc;
+    SSLConnRec *scr;
+
+    /*
+     * find corresponding server
+     */
+    if (!(c = (conn_rec *)SSL_get_app_data((SSL *)ssl))) {
+        return;
+    }
+
+    scr = myConnConfig(c);
+    if (!scr) {
+        return;
+    }
+
+    /* If the reneg state is to reject renegotiations, check the SSL
+     * state machine and move to ABORT if a Client Hello is being
+     * read. */
+    if ((where & SSL_CB_ACCEPT_LOOP) && scr->reneg_state == RENEG_REJECT)
{
+        int state = SSL_get_state(ssl);
+        
+        if (state == SSL3_ST_SR_CLNT_HELLO_A 
+            || state == SSL23_ST_SR_CLNT_HELLO_A) {
+            scr->reneg_state = RENEG_ABORT;
+            ap_log_cerror(APLOG_MARK, APLOG_ERR, 0, c,
+                          "rejecting client initiated renegotiation");
+        }
+    }
+    /* If the first handshake is complete, change state to reject any
+     * subsequent client-initated renegotiation. */
+    else if (where & SSL_CB_HANDSHAKE_DONE && scr->reneg_state == RENEG_INIT)
{
+        scr->reneg_state = RENEG_REJECT;
+    }
+
+    s = mySrvFromConn(c);
+    if (!(sc = mySrvConfig(s))) {
+        return;
+    }
+   
+    if (s->loglevel >= APLOG_DEBUG) {
+        log_tracing_state(ssl, s, c, where, rc);
+    }
+}
That's from the patch in my previous post. It actually contains the exact error which you experienced in your log.
 
  


Reply

Tags
ssl


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
apache2 mod_proxy failing with ssl eco Linux - Server 1 05-21-2010 01:58 AM
Problem on SSL Cert creation to use it on https_port directive on Squid crackyblue Linux - Software 0 06-18-2009 02:10 AM
eth1 failing on boot, IEEE firewire card driver failing, help jackuss_169 Linux - Laptop and Netbook 5 03-05-2005 07:34 AM
enabling ssl in apache for imp linuxnube Linux - Software 1 12-29-2003 11:12 AM
LILO install failing, Boot failing, but Installation fine. sramelyk Slackware 9 08-23-2003 02:37 PM


All times are GMT -5. The time now is 05:52 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration