mi chiedevo se nginx è in grado di gestire le richieste http e https sulla stessa porta . [*]

Questo è quello che sto cercando di fare. Sto eseguendo un web server (lighttpd) che gestisce le richieste http e un programma C che serve una particolare sezione dell'albero del documento tramite https. Questi due processi vengono eseguiti sullo stesso server.

A livello di firewall, posso avere solo un port forwarding del traffico su questo server . Quindi quello che mi piacerebbe fare è configurare nginx su questo server in modo che ascolti le richieste su una singola porta e quindi:

A) reindirizza tutte le richieste http://myhost.com/ * in modo che vengano indirizzate a localhost: 8080 (dove lighttpd è in ascolto)

B) se un utente richiede un URL che inizia con, ad esempio, https: // myhost.com/app, invia tale richiesta a localhost: 8008 (programma C). In questo caso, il traffico tra il browser remoto e nginx deve essere crittografato.

Pensi che questo potrebbe essere possibile? Se lo è, come può essere fatto?

So come fare usando due porte diverse. La sfida che sto affrontando sta facendo questo con una sola porta (sfortunatamente, non ho il controllo della configurazione del firewall su questo particolare ambiente, quindi questa è una restrizione che non posso evitare). L'uso di tecniche come il reverse port fowarding tramite ssh per bypassare il firewall non funzionerà neanche, perché questo dovrebbe funzionare per gli utenti remoti che non hanno nient'altro che un browser web e un collegamento Internet.

Se questo va oltre le capacità di nginx, conosci altri prodotti che potrebbero soddisfare questi requisiti? (finora non ho avuto successo nel configurarlo con lighttpd e pound). Preferirei anche evitare Apache (anche se sono disposto a usarlo se è l'unica scelta possibile).

Grazie in anticipo, Alex

[*] Per essere chiari, sto parlando della gestione di connessioni HTTP crittografate e non crittografate attraverso la stessa porta. Non importa se la crittografia viene eseguita tramite SSL o TLS.

Secondo l'articolo di Wikipedia sui codici di stato, Nginx ha un codice di errore personalizzato quando il traffico http viene inviato alla porta https (codice di errore 497)

E secondo i documenti nginx su pagina_errore , è possibile definire un URI che verrà mostrato per un errore specifico.
Pertanto, possiamo creare un uri a cui verranno inviati i client quando viene generato il codice di errore 497.

nginx.conf

#lets assume your IP address is 89.89.89.89 and also that you want nginx to listen on port 7000 and your app is running on port 3000

server {
    listen 7000 ssl;

    ssl_certificate /path/to/ssl_certificate.cer;
    ssl_certificate_key /path/to/ssl_certificate_key.key;
    ssl_client_certificate /path/to/ssl_client_certificate.cer;

    error_page 497 301 =307 https://89.89.89.89:7000$request_uri;

    location / {
        proxy_pass http://89.89.89.89:3000/;

        proxy_pass_header Server;
        proxy_set_header Host $http_host;
        proxy_redirect off;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Protocol $scheme;
    }
}

Tuttavia, se un client effettua una richiesta tramite qualsiasi altro metodo tranne un GET, tale richiesta verrà trasformata in un GET. Pertanto, per preservare il metodo di richiesta tramite il quale il client è entrato; usiamo i reindirizzamenti dell'elaborazione degli errori, come mostrato nei documenti nginx su pagina_errore

Ed è per questo che usiamo il 301 =307reindirizzamento.

Usando il file nginx.conf mostrato qui, possiamo avere http e https in ascolto sulla stessa porta

Per coloro che potrebbero essere alla ricerca:

Aggiungi ssl on;e error_page 497 $request_uri;alla definizione del tuo server.

Se vuoi essere davvero intelligente, potresti utilizzare una cosa proxy di connessione per annusare i primi due byte del flusso di dati in entrata e distribuire la connessione in base al contenuto del byte 0: se è 0x16 (SSL / TLS ' handshake 'byte), passa la connessione al lato SSL, se è un carattere alfabetico, esegui il normale HTTP. Si applica il mio commento sulla numerazione delle porte .

Sì, è possibile, ma ha bisogno di patchare il codice sorgente di nginx (HoverHell ha una soluzione senza patchare). Nginx lo considera come una configurazione errata piuttosto che una configurazione valida.

La variabile $ ssl_session_id può essere utilizzata per differenziare tra connessione plain e ssl.

Patch contro nginx-0.7.65:

--- src/http/ngx_http_request.c-orig    2011-05-03 15:47:09.000000000 +0200
+++ src/http/ngx_http_request.c 2011-05-03 15:44:01.000000000 +0200
@@ -1545,12 +1545,14 @@

    c = r->connection;

+    /* disable plain http over https port warning
     if (r->plain_http) {
         ngx_log_error(NGX_LOG_INFO, c->log, 0,
                       "client sent plain HTTP request to HTTPS port");
         ngx_http_finalize_request(r, NGX_HTTP_TO_HTTPS);
         return;
     }
+    */

#if (NGX_HTTP_SSL)

Config server:

server {
    listen 80;
    index index.html;

    location / {
        root html;
        if ($ssl_session_id) {
            root html_ssl;
        }
    }

    ssl on;
    ssl_certificate cert.crt;
    ssl_certificate_key cert.key;
}

Non credo che ci sia qualcosa in grado di gestire due protocolli diversi su una singola porta ...

Sono curioso di sapere perché puoi inoltrare solo una porta, ma a parte questo ... non è l'ideale ma se fossi nei tuoi panni, servirei tutto su https.

Non è possibile supportare sia HTTP che HTTPS sulla stessa porta, poiché entrambe le estremità della connessione si aspettano di parlare una determinata lingua e non sono abbastanza intelligenti da capire se l'altra estremità parla qualcos'altro.

Come il vostro commento alla risposta di Wil ha suggerito, si potrebbe utilizzare l'aggiornamento TLS (credo release nginx più recenti supportano, anche se non ho provato), ma che non è in esecuzione HTTP e HTTPS, che è solo in esecuzione HTTP con aggiornamento TLS. Il problema è ancora il supporto del browser - la maggior parte dei browser (ancora) non lo supporta. Se hai un pool limitato di clienti, questa è comunque una possibilità.

Non sono sicuro di come lo risolva, ma CUPSD risponde sia a http che a https sulla porta 631. Se nginx non può farlo ora, forse possono imparare da come il team CUPS lo esegue, ma CUPS è sotto GPL, quindi nginx potrebbe dover cercare di cambiare la propria licenza se vogliono implementare tale capacità e non riescono a trovare il codice per farlo altrove.

In teoria, potresti avere una pagina web accessibile via HTTP, che è in grado di aprire un WebSocket su https: 443 ovunque tu voglia. L'handshake iniziale di WebSocket è HTTP. Quindi, sì, è possibile rendere una pagina dall'aspetto insicuro effettivamente in grado di comunicare in modo sicuro. Potresti farlo con la Netty Library .

Questo è finalmente possibile farlo correttamente dall'1.15.2. Vedi le informazioni qui .

Nel tuo nginx.conf aggiungi un blocco come questo (fuori dal blocco http):

stream {
    upstream http {
        server localhost:8000;
    }

    upstream https {
        server localhost:8001;
    }

    map $ssl_preread_protocol $upstream {
        default https;
        "" http;
    }

    server {
        listen 8080;
        listen [::]:8080;
        proxy_pass $upstream;
        ssl_preread on;
    }
}

Quindi puoi creare il tuo normale blocco server, ma ascoltando su queste diverse porte:

server {
    listen 8000;
    listen [::]:8000;
    listen 8001 ssl;
    listen [::]:8001 ssl;
...

In questo modo, il blocco di flusso è in grado di pre-leggere e rilevare se è TLS o meno (sulla porta 8080 in questo esempio), quindi il proxy lo passa localmente alla porta del server corretta.