Vendor Connection via Proxy to SNI Server response 403 Forbidden

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Vendor Connection via Proxy to SNI Server response 403 Forbidden

Reid Watson
Hi Everyone,  

There are few posts going around and I was wondering if any one had some advice or experienced a similar issues

Current Apache Version: httpd-2.4.12

Issue

- External Vendor WebServer enables SNI check
- I currently connect to vendor via proxy (from Http to Https)
- I disable ssl checks on the certificate
- Each time we make a connection I’m returned 403, the reason is the vendor enables SNI check and within the Client Hello (SSL Handshake) packet we set ServerName from vHost “Internal-site.test.com”

Basic config

<VirtualHost *:*>
     
     ServerName Internal-site.test.com

      SSLProxyCheckPeerName off
      SSLProxyCheckPeerCN off
      SSLProxyCheckPeerExpire off

     RewriteCond %{REQUEST_URI} ^/path
     RewriteRule ^/path/(.*) https://vendor-site.com/$1 [P,L,E=vendor-site.com]

</VirtualHost>

Does any one have any advice on the current issue or a trick / workaround with mod_ssl / mod_proxy

for example would I attempt to overwrite the environment variable "SetEnv SSL_TLS_SNI vendor-site.com” ?

Thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Vendor Connection via Proxy to SNI Server response 403 Forbidden

Luca Toscano
Hi Reid,

2017-06-03 3:11 GMT+02:00 Reid Watson <[hidden email]>:
Hi Everyone,

There are few posts going around and I was wondering if any one had some advice or experienced a similar issues

Current Apache Version: httpd-2.4.12

Issue

- External Vendor WebServer enables SNI check
- I currently connect to vendor via proxy (from Http to Https)
- I disable ssl checks on the certificate
- Each time we make a connection I’m returned 403, the reason is the vendor enables SNI check and within the Client Hello (SSL Handshake) packet we set ServerName from vHost “Internal-site.test.com

Basic config

<VirtualHost *:*>

     ServerName Internal-site.test.com

      SSLProxyCheckPeerName off
      SSLProxyCheckPeerCN off
      SSLProxyCheckPeerExpire off

     RewriteCond %{REQUEST_URI} ^/path
     RewriteRule ^/path/(.*) https://vendor-site.com/$1 [P,L,E=vendor-site.com]

</VirtualHost>

Does any one have any advice on the current issue or a trick / workaround with mod_ssl / mod_proxy

for example would I attempt to overwrite the environment variable "SetEnv SSL_TLS_SNI vendor-site.com” ?

My understanding is that you want to have a (reverse) http proxy that respond to Internal-site.test.com with the content of vendor-site.com, leaving to httpd the responsibility to set the "right" TLS SNI domain (in this case the one that you want is vendor-site.com).

Is my understanding correct? Can you please turn loglevel to trace8 (https://httpd.apache.org/docs/2.4/mod/core.html#loglevel) and show us what httpd logs during a request that returns 403?

Luca 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Vendor Connection via Proxy to SNI Server response 403 Forbidden

Reid Watson

Hi Luca,


"My understanding is that you want to have a (reverse) http proxy that respond to Internal-site.test.com with the content of vendor-site.com, leaving to httpd the responsibility to set the "right" TLS SNI domain (in this case the one that you want is vendor-site.com).

Is my understanding correct?"

You are correct and I will turn on extra logging "trace8" tomorrow morning and complete further testing..


From: Luca Toscano <[hidden email]>
Sent: 06 June 2017 03:30
To: [hidden email]
Subject: Re: [users@httpd] Vendor Connection via Proxy to SNI Server response 403 Forbidden
 
Hi Reid,

2017-06-03 3:11 GMT+02:00 Reid Watson <[hidden email]>:
Hi Everyone,

There are few posts going around and I was wondering if any one had some advice or experienced a similar issues

Current Apache Version: httpd-2.4.12

Issue

- External Vendor WebServer enables SNI check
- I currently connect to vendor via proxy (from Http to Https)
- I disable ssl checks on the certificate
- Each time we make a connection I’m returned 403, the reason is the vendor enables SNI check and within the Client Hello (SSL Handshake) packet we set ServerName from vHost “Internal-site.test.com

Basic config

<VirtualHost *:*>

     ServerName Internal-site.test.com

      SSLProxyCheckPeerName off
      SSLProxyCheckPeerCN off
      SSLProxyCheckPeerExpire off

     RewriteCond %{REQUEST_URI} ^/path
     RewriteRule ^/path/(.*) https://vendor-site.com/$1 [P,L,E=vendor-site.com]

</VirtualHost>

Does any one have any advice on the current issue or a trick / workaround with mod_ssl / mod_proxy

for example would I attempt to overwrite the environment variable "SetEnv SSL_TLS_SNI vendor-site.com” ?

My understanding is that you want to have a (reverse) http proxy that respond to Internal-site.test.com with the content of vendor-site.com, leaving to httpd the responsibility to set the "right" TLS SNI domain (in this case the one that you want is vendor-site.com).

Is my understanding correct? Can you please turn loglevel to trace8 (https://httpd.apache.org/docs/2.4/mod/core.html#loglevel) and show us what httpd logs during a request that returns 403?

Luca 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Vendor Connection via Proxy to SNI Server response 403 Forbidden

Reid Watson
Hi Luca,

I think the vendor is might be putting me down the wrong path because I receive

"[Wed Jun 07 11:54:29.302145 2017] [ssl:trace3] [pid 9177:tid 140532624602880] ssl_engine_kernel.c(1807): [remote 54.230.144.17:443] OpenSSL: Write: SSL negotiation finished successfully"

I thought I would receive "SNI Hostname Error” if I had a mismatch
 
auckland.collegescheduler.com (54.230.144.17) = External Vendor

Log Snippet

[Wed Jun 07 11:54:28.750881 2017] [proxy:debug] [pid 9177:tid 140532624602880] proxy_util.c(2394): [client 10.0.0.1:19478] AH00947: connected /api/institutiondata/xxxxxxxx/COHORTS to auckland.collegescheduler.com:443
[Wed Jun 07 11:54:28.886833 2017] [proxy:debug] [pid 9177:tid 140532624602880] proxy_util.c(2771): AH02824: HTTPS: connection established with 54.230.144.17:443 (*)
[Wed Jun 07 11:54:28.886887 2017] [proxy:debug] [pid 9177:tid 140532624602880] proxy_util.c(2923): AH00962: HTTPS: connection complete to 54.230.144.17:443 (auckland.collegescheduler.com)
[Wed Jun 07 11:54:28.886897 2017] [ssl:info] [pid 9177:tid 140532624602880] [remote 54.230.144.17:443] AH01964: Connection to child 0 established (server Internal-site.test.com:80)
[Wed Jun 07 11:54:28.886921 2017] [ssl:trace2] [pid 9177:tid 140532624602880] ssl_engine_rand.c(124): Seeding PRNG with 144 bytes of entropy
[Wed Jun 07 11:54:28.886985 2017] [ssl:trace4] [pid 9177:tid 140532624602880] ssl_engine_io.c(1489): [remote 54.230.144.17:443] coalesce: have 0 bytes, adding 776 more
[Wed Jun 07 11:54:28.886993 2017] [ssl:trace4] [pid 9177:tid 140532624602880] ssl_engine_io.c(1551): [remote 54.230.144.17:443] coalesce: passing on 545 bytes
[Wed Jun 07 11:54:28.887001 2017] [ssl:trace3] [pid 9177:tid 140532624602880] ssl_engine_io.c(1086): [remote 54.230.144.17:443] SNI extension for SSL Proxy request set to 'Internal-site.test.com'
[Wed Jun 07 11:54:28.887011 2017] [ssl:trace3] [pid 9177:tid 140532624602880] ssl_engine_kernel.c(1788): [remote 54.230.144.17:443] OpenSSL: Handshake: start
[Wed Jun 07 11:54:28.887022 2017] [ssl:trace3] [pid 9177:tid 140532624602880] ssl_engine_kernel.c(1797): [remote 54.230.144.17:443] OpenSSL: Loop: before/connect initialization
[Wed Jun 07 11:54:28.887040 2017] [ssl:trace4] [pid 9177:tid 140532624602880] ssl_engine_io.c(2050): [remote 54.230.144.17:443] OpenSSL: write 277/277 bytes to BIO#7fd04400ad80 [mem: 7fd044021b10] (BIO dump follows)

[Wed Jun 07 11:54:28.887149 2017] [ssl:trace3] [pid 9177:tid 140532624602880] ssl_engine_kernel.c(1797): [remote 54.230.144.17:443] OpenSSL: Loop: SSLv2/v3 write client hello A
[Wed Jun 07 11:54:28.887154 2017] [core:trace6] [pid 9177:tid 140532624602880] core_filters.c(527): [remote 54.230.144.17:443] core_output_filter: flushing because of FLUSH bucket
[Wed Jun 07 11:54:29.024967 2017] [ssl:trace4] [pid 9177:tid 140532624602880] ssl_engine_io.c(2050): [remote 54.230.144.17:443] OpenSSL: read 7/7 bytes from BIO#7fd044019290 [mem: 7fd00c024be0] (BIO dump follows)

[Wed Jun 07 11:54:29.165225 2017] [ssl:trace3] [pid 9177:tid 140532624602880] ssl_engine_kernel.c(1797): [remote 54.230.144.17:443] OpenSSL: Loop: SSLv3 read finished A
[Wed Jun 07 11:54:29.165239 2017] [ssl:trace3] [pid 9177:tid 140532624602880] ssl_engine_kernel.c(1792): [remote 54.230.144.17:443] OpenSSL: Handshake: done
[Wed Jun 07 11:54:29.165269 2017] [ssl:debug] [pid 9177:tid 140532624602880] ssl_engine_kernel.c(1841): [remote 54.230.144.17:443] AH02041: Protocol: TLSv1.2, Cipher: ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
[Wed Jun 07 11:54:29.165288 2017] [ssl:trace4] [pid 9177:tid 140532624602880] ssl_engine_io.c(2050): [remote 54.230.144.17:443] OpenSSL: write 574/574 bytes to BIO#7fd04400ad80 [mem: 7fd00c02cd33] (BIO dump follows)

[Wed Jun 07 11:54:29.302044 2017] [proxy_http:trace3] [pid 9177:tid 140532624602880] mod_proxy_http.c(1424): [client 10.0.0.1:19478] Status from backend: 403
[Wed Jun 07 11:54:29.302056 2017] [proxy_http:trace4] [pid 9177:tid 140532624602880] mod_proxy_http.c(1099): [client 10.0.0.1:19478] Headers received from backend:
[Wed Jun 07 11:54:29.302063 2017] [proxy_http:trace4] [pid 9177:tid 140532624602880] mod_proxy_http.c(1101): [client 10.0.0.1:19478] Server: CloudFront
[Wed Jun 07 11:54:29.302068 2017] [proxy_http:trace4] [pid 9177:tid 140532624602880] mod_proxy_http.c(1101): [client 10.0.0.1:19478] Date: Tue, 06 Jun 2017 23:54:29 GMT
[Wed Jun 07 11:54:29.302075 2017] [proxy_http:trace4] [pid 9177:tid 140532624602880] mod_proxy_http.c(1101): [client 10.0.0.1:19478] Content-Type: text/html
[Wed Jun 07 11:54:29.302078 2017] [proxy_http:trace4] [pid 9177:tid 140532624602880] mod_proxy_http.c(1101): [client 10.0.0.1:19478] Content-Length: 555
[Wed Jun 07 11:54:29.302082 2017] [proxy_http:trace4] [pid 9177:tid 140532624602880] mod_proxy_http.c(1101): [client 10.0.0.1:19478] Connection: close
[Wed Jun 07 11:54:29.302085 2017] [proxy_http:trace4] [pid 9177:tid 140532624602880] mod_proxy_http.c(1101): [client 10.0.0.1:19478] X-Cache: Error from cloudfront
[Wed Jun 07 11:54:29.302089 2017] [proxy_http:trace4] [pid 9177:tid 140532624602880] mod_proxy_http.c(1101): [client 10.0.0.1:19478] Via: 1.1 515297ac55a7ae01bf8c7d03df4fecb1.cloudfront.net (CloudFront)
[Wed Jun 07 11:54:29.302092 2017] [proxy_http:trace4] [pid 9177:tid 140532624602880] mod_proxy_http.c(1101): [client 10.0.0.1:19478] X-Amz-Cf-Id: xxxxxxxx
[Wed Jun 07 11:54:29.302103 2017] [proxy_http:trace3] [pid 9177:tid 140532624602880] mod_proxy_http.c(1687): [client 10.0.0.1:19478] start body send
[Wed Jun 07 11:54:29.302111 2017] [proxy:debug] [pid 9177:tid 140532624602880] proxy_util.c(2155): AH00943: *: has released connection for (*)
[Wed Jun 07 11:54:29.302124 2017] [ssl:trace4] [pid 9177:tid 140532624602880] ssl_engine_io.c(2050): [remote 54.230.144.17:443] OpenSSL: write 31/31 bytes to BIO#7fd04400ad80 [mem: 7fd00c02cd33] (BIO dump follows)
[Wed Jun 07 11:54:29.302145 2017] [ssl:trace3] [pid 9177:tid 140532624602880] ssl_engine_kernel.c(1807): [remote 54.230.144.17:443] OpenSSL: Write: SSL negotiation finished successfully
[Wed Jun 07 11:54:29.302149 2017] [core:trace6] [pid 9177:tid 140532624602880] core_filters.c(527): [remote 54.230.144.17:443] core_output_filter: flushing because of FLUSH bucket
[Wed Jun 07 11:54:29.302188 2017] [ssl:debug] [pid 9177:tid 140532624602880] ssl_engine_io.c(1003): [remote 54.230.144.17:443] AH02001: Connection closed to child 0 with standard shutdown (server Internal-site.test.com:80)
[Wed Jun 07 11:54:29.302281 2017] [proxy:debug] [pid 9177:tid 140532624602880] proxy_util.c(2864): [remote 54.230.144.17:443] AH02642: proxy: connection shutdown
[Wed Jun 07 11:54:29.302323 2017] [headers:trace2] [pid 9177:tid 140532624602880] mod_headers.c(874): AH01502: headers: ap_headers_output_filter()

Cheers

Reid

> On 6/06/2017, at 10:17 PM, Reid Watson <[hidden email]> wrote:
>
> Hi Luca,
>
> "My understanding is that you want to have a (reverse) http proxy that respond to Internal-site.test.com with the content of vendor-site.com, leaving to httpd the responsibility to set the "right" TLS SNI domain (in this case the one that you want is vendor-site.com).
>
> Is my understanding correct?"
>
> You are correct and I will turn on extra logging "trace8" tomorrow morning and complete further testing..
>
> From: Luca Toscano <[hidden email]>
> Sent: 06 June 2017 03:30
> To: [hidden email]
> Subject: Re: [users@httpd] Vendor Connection via Proxy to SNI Server response 403 Forbidden
>  
> Hi Reid,
>
> 2017-06-03 3:11 GMT+02:00 Reid Watson <[hidden email]>:
> Hi Everyone,
>
> There are few posts going around and I was wondering if any one had some advice or experienced a similar issues
>
> Current Apache Version: httpd-2.4.12
>
> Issue
>
> - External Vendor WebServer enables SNI check
> - I currently connect to vendor via proxy (from Http to Https)
> - I disable ssl checks on the certificate
> - Each time we make a connection I’m returned 403, the reason is the vendor enables SNI check and within the Client Hello (SSL Handshake) packet we set ServerName from vHost “Internal-site.test.com”
>
> Basic config
>
> <VirtualHost *:*>
>
>      ServerName Internal-site.test.com
>
>       SSLProxyCheckPeerName off
>       SSLProxyCheckPeerCN off
>       SSLProxyCheckPeerExpire off
>
>      RewriteCond %{REQUEST_URI} ^/path
>      RewriteRule ^/path/(.*) https://vendor-site.com/$1 [P,L,E=vendor-site.com]
>
> </VirtualHost>
>
> Does any one have any advice on the current issue or a trick / workaround with mod_ssl / mod_proxy
>
> for example would I attempt to overwrite the environment variable "SetEnv SSL_TLS_SNI vendor-site.com” ?
>
> My understanding is that you want to have a (reverse) http proxy that respond to Internal-site.test.com with the content of vendor-site.com, leaving to httpd the responsibility to set the "right" TLS SNI domain (in this case the one that you want is vendor-site.com).
>
> Is my understanding correct? Can you please turn loglevel to trace8 (https://httpd.apache.org/docs/2.4/mod/core.html#loglevel) and show us what httpd logs during a request that returns 403?
>
> Luca
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Vendor Connection via Proxy to SNI Server response 403 Forbidden

Luca Toscano


2017-06-07 2:42 GMT+02:00 Reid Watson <[hidden email]>:
Hi Luca,

I think the vendor is might be putting me down the wrong path because I receive

"[Wed Jun 07 11:54:29.302145 2017] [ssl:trace3] [pid 9177:tid 140532624602880] ssl_engine_kernel.c(1807): [remote 54.230.144.17:443] OpenSSL: Write: SSL negotiation finished successfully"

I thought I would receive "SNI Hostname Error” if I had a mismatch

auckland.collegescheduler.com (54.230.144.17) = External Vendor

Log Snippet

[Wed Jun 07 11:54:28.750881 2017] [proxy:debug] [pid 9177:tid 140532624602880] proxy_util.c(2394): [client 10.0.0.1:19478] AH00947: connected /api/institutiondata/xxxxxxxx/COHORTS to auckland.collegescheduler.com:443
[Wed Jun 07 11:54:28.886833 2017] [proxy:debug] [pid 9177:tid 140532624602880] proxy_util.c(2771): AH02824: HTTPS: connection established with 54.230.144.17:443 (*)
[Wed Jun 07 11:54:28.886887 2017] [proxy:debug] [pid 9177:tid 140532624602880] proxy_util.c(2923): AH00962: HTTPS: connection complete to 54.230.144.17:443 (auckland.collegescheduler.com)
[Wed Jun 07 11:54:28.886897 2017] [ssl:info] [pid 9177:tid 140532624602880] [remote 54.230.144.17:443] AH01964: Connection to child 0 established (server Internal-site.test.com:80)
[Wed Jun 07 11:54:28.886921 2017] [ssl:trace2] [pid 9177:tid 140532624602880] ssl_engine_rand.c(124): Seeding PRNG with 144 bytes of entropy
[Wed Jun 07 11:54:28.886985 2017] [ssl:trace4] [pid 9177:tid 140532624602880] ssl_engine_io.c(1489): [remote 54.230.144.17:443] coalesce: have 0 bytes, adding 776 more
[Wed Jun 07 11:54:28.886993 2017] [ssl:trace4] [pid 9177:tid 140532624602880] ssl_engine_io.c(1551): [remote 54.230.144.17:443] coalesce: passing on 545 bytes
[Wed Jun 07 11:54:28.887001 2017] [ssl:trace3] [pid 9177:tid 140532624602880] ssl_engine_io.c(1086): [remote 54.230.144.17:443] SNI extension for SSL Proxy request set to 'Internal-site.test.com'
[Wed Jun 07 11:54:28.887011 2017] [ssl:trace3] [pid 9177:tid 140532624602880] ssl_engine_kernel.c(1788): [remote 54.230.144.17:443] OpenSSL: Handshake: start
[Wed Jun 07 11:54:28.887022 2017] [ssl:trace3] [pid 9177:tid 140532624602880] ssl_engine_kernel.c(1797): [remote 54.230.144.17:443] OpenSSL: Loop: before/connect initialization
[Wed Jun 07 11:54:28.887040 2017] [ssl:trace4] [pid 9177:tid 140532624602880] ssl_engine_io.c(2050): [remote 54.230.144.17:443] OpenSSL: write 277/277 bytes to BIO#7fd04400ad80 [mem: 7fd044021b10] (BIO dump follows)

[Wed Jun 07 11:54:28.887149 2017] [ssl:trace3] [pid 9177:tid 140532624602880] ssl_engine_kernel.c(1797): [remote 54.230.144.17:443] OpenSSL: Loop: SSLv2/v3 write client hello A
[Wed Jun 07 11:54:28.887154 2017] [core:trace6] [pid 9177:tid 140532624602880] core_filters.c(527): [remote 54.230.144.17:443] core_output_filter: flushing because of FLUSH bucket
[Wed Jun 07 11:54:29.<a href="tel:024967%202017" value="+390249672017">024967 2017] [ssl:trace4] [pid 9177:tid 140532624602880] ssl_engine_io.c(2050): [remote 54.230.144.17:443] OpenSSL: read 7/7 bytes from BIO#7fd044019290 [mem: 7fd00c024be0] (BIO dump follows)

[Wed Jun 07 11:54:29.165225 2017] [ssl:trace3] [pid 9177:tid 140532624602880] ssl_engine_kernel.c(1797): [remote 54.230.144.17:443] OpenSSL: Loop: SSLv3 read finished A
[Wed Jun 07 11:54:29.165239 2017] [ssl:trace3] [pid 9177:tid 140532624602880] ssl_engine_kernel.c(1792): [remote 54.230.144.17:443] OpenSSL: Handshake: done
[Wed Jun 07 11:54:29.165269 2017] [ssl:debug] [pid 9177:tid 140532624602880] ssl_engine_kernel.c(1841): [remote 54.230.144.17:443] AH02041: Protocol: TLSv1.2, Cipher: ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
[Wed Jun 07 11:54:29.165288 2017] [ssl:trace4] [pid 9177:tid 140532624602880] ssl_engine_io.c(2050): [remote 54.230.144.17:443] OpenSSL: write 574/574 bytes to BIO#7fd04400ad80 [mem: 7fd00c02cd33] (BIO dump follows)

[Wed Jun 07 11:54:29.302044 2017] [proxy_http:trace3] [pid 9177:tid 140532624602880] mod_proxy_http.c(1424): [client 10.0.0.1:19478] Status from backend: 403
[Wed Jun 07 11:54:29.302056 2017] [proxy_http:trace4] [pid 9177:tid 140532624602880] mod_proxy_http.c(1099): [client 10.0.0.1:19478] Headers received from backend:
[Wed Jun 07 11:54:29.302063 2017] [proxy_http:trace4] [pid 9177:tid 140532624602880] mod_proxy_http.c(1101): [client 10.0.0.1:19478] Server: CloudFront
[Wed Jun 07 11:54:29.302068 2017] [proxy_http:trace4] [pid 9177:tid 140532624602880] mod_proxy_http.c(1101): [client 10.0.0.1:19478] Date: Tue, 06 Jun 2017 23:54:29 GMT
[Wed Jun 07 11:54:29.302075 2017] [proxy_http:trace4] [pid 9177:tid 140532624602880] mod_proxy_http.c(1101): [client 10.0.0.1:19478] Content-Type: text/html
[Wed Jun 07 11:54:29.302078 2017] [proxy_http:trace4] [pid 9177:tid 140532624602880] mod_proxy_http.c(1101): [client 10.0.0.1:19478] Content-Length: 555
[Wed Jun 07 11:54:29.302082 2017] [proxy_http:trace4] [pid 9177:tid 140532624602880] mod_proxy_http.c(1101): [client 10.0.0.1:19478] Connection: close
[Wed Jun 07 11:54:29.302085 2017] [proxy_http:trace4] [pid 9177:tid 140532624602880] mod_proxy_http.c(1101): [client 10.0.0.1:19478] X-Cache: Error from cloudfront
[Wed Jun 07 11:54:29.302089 2017] [proxy_http:trace4] [pid 9177:tid 140532624602880] mod_proxy_http.c(1101): [client 10.0.0.1:19478] Via: 1.1 515297ac55a7ae01bf8c7d03df4fecb1.cloudfront.net (CloudFront)
[Wed Jun 07 11:54:29.302092 2017] [proxy_http:trace4] [pid 9177:tid 140532624602880] mod_proxy_http.c(1101): [client 10.0.0.1:19478] X-Amz-Cf-Id: xxxxxxxx


This one is interesting: Cloudfront seems to return 403 to you. I don't see any particular TLS related error from the logs, I'd focus on checking one level up (HTTP :)

Luca
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Vendor Connection via Proxy to SNI Server response 403 Forbidden

Luca Toscano
In reply to this post by Reid Watson
Hi Reid,

 while re-reading the logs I noticed one thing: 

2017-06-07 2:42 GMT+02:00 Reid Watson <[hidden email]>:

[Wed Jun 07 11:54:28.887001 2017] [ssl:trace3] [pid 9177:tid 140532624602880] ssl_engine_io.c(1086): [remote 54.230.144.17:443] SNI extension for SSL Proxy request set to 'Internal-site.test.com'
[Wed Jun 07 11:54:28.887011 2017] [ssl:trace3] [pid 9177:tid 140532624602880] ssl_engine_kernel.c(1788): [remote 54.230.144.17:443] OpenSSL: Handshake: start
[..] 
[Wed Jun 07 11:54:29.302044 2017] [proxy_http:trace3] [pid 9177:tid 140532624602880] mod_proxy_http.c(1424): [client 10.0.0.1:19478] Status from backend: 403
[Wed Jun 07 11:54:29.302056 2017] [proxy_http:trace4] [pid 9177:tid 140532624602880] mod_proxy_http.c(1099): [client 10.0.0.1:19478] Headers received from backend:
[Wed Jun 07 11:54:29.302063 2017] [proxy_http:trace4] [pid 9177:tid 140532624602880] mod_proxy_http.c(1101): [client 10.0.0.1:19478] Server: CloudFront
[Wed Jun 07 11:54:29.302068 2017] [proxy_http:trace4] [pid 9177:tid 140532624602880] mod_proxy_http.c(1101): [client 10.0.0.1:19478] Date: Tue, 06 Jun 2017 23:54:29 GMT
[Wed Jun 07 11:54:29.302075 2017] [proxy_http:trace4] [pid 9177:tid 140532624602880] mod_proxy_http.c(1101): [client 10.0.0.1:19478] Content-Type: text/html
[Wed Jun 07 11:54:29.302078 2017] [proxy_http:trace4] [pid 9177:tid 140532624602880] mod_proxy_http.c(1101): [client 10.0.0.1:19478] Content-Length: 555
[Wed Jun 07 11:54:29.302082 2017] [proxy_http:trace4] [pid 9177:tid 140532624602880] mod_proxy_http.c(1101): [client 10.0.0.1:19478] Connection: close
[Wed Jun 07 11:54:29.302085 2017] [proxy_http:trace4] [pid 9177:tid 140532624602880] mod_proxy_http.c(1101): [client 10.0.0.1:19478] X-Cache: Error from cloudfront
[Wed Jun 07 11:54:29.302089 2017] [proxy_http:trace4] [pid 9177:tid 140532624602880] mod_proxy_http.c(1101): [client 10.0.0.1:19478] Via: 1.1 515297ac55a7ae01bf8c7d03df4fecb1.cloudfront.net (CloudFront)
[Wed Jun 07 11:54:29.302092 2017] [proxy_http:trace4] [pid 9177:tid 140532624602880] mod_proxy_http.c(1101): [client 10.0.0.1:19478] X-Amz-Cf-Id: xxxxxxxx
[Wed Jun 07 11:54:29.302103 2017] [proxy_http:trace3] [pid 9177:tid 140532624602880] mod_proxy_http.c(1687): [client 10.0.0.1:19478] start body send

There is a clear indication that the SNI is wrong: 

SNI extension for SSL Proxy request set to 'Internal-site.test.com'

So my understanding is that you perform correctly the TLS handshake to Amazon Cloudfront (used as CDN), but since the SNI is wrong you get a 403 from the backend. Can you try to replace your Rewrite rules with mod_proxy_http and ProxyPass (https://httpd.apache.org/docs/2.4/mod/mod_proxy.html) and see if anything changes (namely if the SNI is set to the one that you expect) ?

Luca

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Vendor Connection via Proxy to SNI Server response 403 Forbidden

Reid Watson
Hi Luca,  

Just thought you would like to know the Vendor changed his end on CloudFront and this has addressed the issue.. I don’t have any details from the vendor but thank you for your advice..

Cheers

Reid

> On 8/06/2017, at 9:43 PM, Luca Toscano <[hidden email]> wrote:
>
> Hi Reid,
>
>  while re-reading the logs I noticed one thing:
>
> 2017-06-07 2:42 GMT+02:00 Reid Watson <[hidden email]>:
>
> [Wed Jun 07 11:54:28.887001 2017] [ssl:trace3] [pid 9177:tid 140532624602880] ssl_engine_io.c(1086): [remote 54.230.144.17:443] SNI extension for SSL Proxy request set to 'Internal-site.test.com'
> [Wed Jun 07 11:54:28.887011 2017] [ssl:trace3] [pid 9177:tid 140532624602880] ssl_engine_kernel.c(1788): [remote 54.230.144.17:443] OpenSSL: Handshake: start
> [..]
> [Wed Jun 07 11:54:29.302044 2017] [proxy_http:trace3] [pid 9177:tid 140532624602880] mod_proxy_http.c(1424): [client 10.0.0.1:19478] Status from backend: 403
> [Wed Jun 07 11:54:29.302056 2017] [proxy_http:trace4] [pid 9177:tid 140532624602880] mod_proxy_http.c(1099): [client 10.0.0.1:19478] Headers received from backend:
> [Wed Jun 07 11:54:29.302063 2017] [proxy_http:trace4] [pid 9177:tid 140532624602880] mod_proxy_http.c(1101): [client 10.0.0.1:19478] Server: CloudFront
> [Wed Jun 07 11:54:29.302068 2017] [proxy_http:trace4] [pid 9177:tid 140532624602880] mod_proxy_http.c(1101): [client 10.0.0.1:19478] Date: Tue, 06 Jun 2017 23:54:29 GMT
> [Wed Jun 07 11:54:29.302075 2017] [proxy_http:trace4] [pid 9177:tid 140532624602880] mod_proxy_http.c(1101): [client 10.0.0.1:19478] Content-Type: text/html
> [Wed Jun 07 11:54:29.302078 2017] [proxy_http:trace4] [pid 9177:tid 140532624602880] mod_proxy_http.c(1101): [client 10.0.0.1:19478] Content-Length: 555
> [Wed Jun 07 11:54:29.302082 2017] [proxy_http:trace4] [pid 9177:tid 140532624602880] mod_proxy_http.c(1101): [client 10.0.0.1:19478] Connection: close
> [Wed Jun 07 11:54:29.302085 2017] [proxy_http:trace4] [pid 9177:tid 140532624602880] mod_proxy_http.c(1101): [client 10.0.0.1:19478] X-Cache: Error from cloudfront
> [Wed Jun 07 11:54:29.302089 2017] [proxy_http:trace4] [pid 9177:tid 140532624602880] mod_proxy_http.c(1101): [client 10.0.0.1:19478] Via: 1.1 515297ac55a7ae01bf8c7d03df4fecb1.cloudfront.net (CloudFront)
> [Wed Jun 07 11:54:29.302092 2017] [proxy_http:trace4] [pid 9177:tid 140532624602880] mod_proxy_http.c(1101): [client 10.0.0.1:19478] X-Amz-Cf-Id: xxxxxxxx
> [Wed Jun 07 11:54:29.302103 2017] [proxy_http:trace3] [pid 9177:tid 140532624602880] mod_proxy_http.c(1687): [client 10.0.0.1:19478] start body send
>
> There is a clear indication that the SNI is wrong:
>
> SNI extension for SSL Proxy request set to 'Internal-site.test.com'
>
> So my understanding is that you perform correctly the TLS handshake to Amazon Cloudfront (used as CDN), but since the SNI is wrong you get a 403 from the backend. Can you try to replace your Rewrite rules with mod_proxy_http and ProxyPass (https://httpd.apache.org/docs/2.4/mod/mod_proxy.html) and see if anything changes (namely if the SNI is set to the one that you expect) ?
>
> Luca
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Loading...