SSL Protocol error - I am lost!

Hello everyone

It’s my first time writing here, I’ve been reading a lot, and I want to say thank you to everyone who share their knowledge here, you all have been a tremendous help for me.

I did all I could to try an figure this thing out before posting here, by reading and trying everything I could find in this community and in many others as well.
Eventually… here I am.

So… Here we go:

Environment

I use a simple but stable isp branded router given to me by my isp of course.
For easy reading, the ip is: 192.168.0.1.

I have Nginx 1.10.3 running with OpenSSL 1.1.0j on my rpi 3b+ running raspbian.
For easy reading, the ip is: 192.168.0.2.

I have pc running Ubuntu 18.04.2 LTS acting as a swarm manager node with docker 18.09.6.
For easy reading, the ip is: 192.168.0.104.

My router is configured to expose the ports 2052 and 2053 to the outside world and redirect their TCP traffic to my nginx on 192.168.0.2.

On my docker station, I’m running a cloud9 ide inside a container exposing the port 1984 to the host network.

Flow

I have two sub-domains configured with cloudflare (domain names and public ip were altered):

Both have a legit DNS A record on my Cloudflare configuration pointing to my public ip.
Therefore both will be directed by my router at 192.168.0.1 and from there to my nginx at 192.168.0.2 based on the ports used (2052, 2053).

My nginx at 192.168.0.2 supplies the certificates and redirects the traffic to my pc at 192.168.0.104 using the port 1984.
(Initially of course every sub-domain and every port had its own destination and its own purpose, I matched the two redirections to each other after a long process of elimination trying to figure out what’s wrong).

Problem

sub1.mydomain.com:2053 - works like a charm with cloudlfare's proxy!
sub2.mydomain.com:2052 - works only when in dns only mode on cloudlfare, If I set it to go though cloudflare's proxy, I get a ERR_SSL_PROTOCOL_ERROR.

Weirder then that, when in proxy mode, I can’t seem to be able to see the incoming traffic anywhere.
I haven’t tried sniffing the network on my router, but as far as logging goes, there is nothing anywhere regarding the error requests, not in my nginx logs, definitely not in my docker logs, and even nothing in my syslog.

It kind of looks like, when in proxy mode requests to sub2.mydomain.com:2052 goes somewhere else and do not reach me (I’m sure that’s not the case, I’m just saying that’s what it looks like.)

Configuration

Cloudflare-DNS

  • Both sub-domains have A records pointing to my exact same public IP.

Cloudflare-Crypto

  • SSL: Full
  • Always Use HTTPS: On
  • HSTS: Off
  • Authenticated Origin Pulls: Off
  • Minumum TLS Version: TLS 1.0
  • Opportunistic Encryption: On
  • TLS 1.3: Disabled
  • Onion Routing: On
  • Automatic HTTPS Rewrites: On
  • Universal SSL: Enabled

Cloudflare-Firewall Rules

  • When (not ssl) Then Block.
  • When (tcp.port == 2052) or (tcp.port == 2053) Then Allow.

Cloudflare-Caching

  • Caching Level: Standard
  • Browser Cache Expiration: 4 hours
  • Always Online: Off
  • Development Mode: Off

Nginx-Server Blocks
sub1.mydomain.com:2053

server {
        server_name sub1.mydomain.com;
        listen 2053 http2;

        add_header Strict-Transport-Security "max-age=31536000; includeSubdomains; preload";

        ssl on;
        ssl_certificate /etc/cloudflare/origin-certificates/fullchain.pem;
        ssl_certificate_key /etc/cloudflare/origin-certificates/privkey.pem;
        ssl_dhparam /etc/nginx/dhparam.d/dh2048.pem;
        ssl_session_cache shared:SUBONE2053:10m;
        ssl_session_timeout 5m;
        ssl_prefer_server_ciphers on;
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";

        access_log /var/log/nginx/subone2053.log;

        proxy_buffering off;

        location / {
                proxy_pass http://192.168.0.144:1984;
                proxy_set_header Host $host;
                proxy_redirect http:// https://;
                proxy_http_version 1.1;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header Upgrade $http_upgrade;
        }
}

sub2.mydomain.com:2052

server {
        server_name sub2.mydomain.com;
        listen 2052 http2;

        add_header Strict-Transport-Security "max-age=31536000; includeSubdomains; preload";

        ssl on;
        ssl_certificate /etc/cloudflare/origin-certificates/fullchain.pem;
        ssl_certificate_key /etc/cloudflare/origin-certificates/privkey.pem;
        ssl_session_cache shared:SUBTWO2052:10m;
        ssl_session_timeout 5m;
        ssl_dhparam /etc/nginx/dhparam.d/dh2048.pem;
        ssl_prefer_server_ciphers on;
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";

        access_log /var/log/nginx/subtwo2052.log;

        proxy_buffering off;

        location / {
                proxy_pass http://192.168.0.144:1984;
                proxy_set_header Host $host;
                proxy_redirect http:// https://;
                proxy_http_version 1.1;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header Upgrade $http_upgrade;
        }

}

Error Demonstration

When trying to access sub2.mydomain.com:2052 in proxy mode I get the following error with the following tools:

Google Chrome

This site can’t provide a secure connection
sub2.mydomain.com sent an invalid response.

ERR_SSL_PROTOCOL_ERROR

Internet Explorer

Can’t connect securely to this page

This might be because the site uses outdated or unsafe TLS security settings.
If this keeps happening, try contacting the website’s owner.

Curl

curl -vL https://sub2.mydomain.com:2052
* Rebuilt URL to: https://sub2.mydomain.com:2052/
*   Trying 111.22.333.444...
* TCP_NODELAY set
* Connected to sub2.mydomain.com (111.22.333.444) port 2052 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
* Curl_http_done: called premature == 1
* stopped the pause stream!
* Closing connection 0
curl: (35) error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol

OpenSSL

openssl s_client -connect sub2.mydomain.com:2052
CONNECTED(00000003)
1996111872:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../ssl/record/ssl3_record.c:252:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 5 bytes and written 176 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1559722770
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
---

I have tried everything…
Switching ports, switching endpoints, turning on and off configuration flags (like the universal ssl).
I’ve waited all the time needed to wait between configuration changes.
I’ve really been at it for more the a week now, and I tried everything and I have no idea what else can I do.

Any Ideas anyone?

Thanks,
Tomer.
:slight_smile:

I admit I did not read your entire posting :blush: so I might have missed something, but I believe to understand the gist is that SSL does not work on port 2052. Is this correct?

If so, then yes, port 2052 is exclusively reserved for HTTP when you are proxying through Cloudflare

1 Like

We have experienced the same error. Only one difference - we use a flexible way for HTTPS. We had problem domain in DNS before certs were issued and we think that it is the root of this issue. But we can’t find where we will be able to recreate certs we think that issue will be gone after recreating. Also, we have tried to remove the subdomain from DNS, then restore - nothing changed. The same issue. Somewhere yet the binding certs/subdomain is stored.

Lets say I scanned it :slight_smile:

Even though it is quite lengthy, I’d still appreciate the level of technical details :+1:t2:. Only actual hostnames and IP addresses could have completed the picture.

1 Like

@sandro
If you happen to visit Israel,
Please let me know - at the very least owe you a cup of coffee!
:coffee:

The funny things is, I know that list.
I referenced others to that list before.

Somehow I was absolutely sure that 2052 is in the https list.
Weirdly enough I was also sure that 2086 and 2095 are also on that list (those are the other ports I’ve tried).
And it hasn’t occurred to me to recheck the list and make sure I remember correctly.

Well…
After wasting a week+,
dumping two projects for the wrong reasons,
and pulling most of my hair out of my head…

I think my lesson here is:
Always double check instructions and do not relay strictly on memory.

Thank you very for the super fast and on-the-point response!

:smiley:

1 Like

Thanks, will add it to my list :smile: a decent coffee is always appreciated :slight_smile:

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.