Обработка http и запросы HTTPS с помощью единственного порта с nginx
Я должен также упомянуть, что XenServer включает все, что необходимо установить сверху чистого металла. С Xen.org необходимо установить его сами, который может быть очень сложным/забавным/интересным (выбор, какой бы ни каждый соответствует контексту).
Если бы Вы хотели быть действительно умными, то Вы могли бы использовать вещь прокси соединения осуществить сниффинг первых двух байтов входящего потока данных и руки от соединения на основе содержания байта 0: если это - 0x16 (байт 'квитирования' SSL/TLS), передайте соединение со стороной SSL, если это - алфавитный символ, сделайте нормальный HTTP. Мой комментарий о нумерации порта применяется.
Я не думаю, что существует что-либо, что может обработать два различных протокола на единственном порте...
Мне любопытно относительно того, почему можно только передать один порт, но что в стороне... это не идеально, но если бы я был месте, то я служил бы всему по https.
-
1Привет Wil и спасибо за Ваш ответ! Я думаю, что обслуживание всего по https могло быть опцией, хотя i' d нравится мочь настроить это в пути который i' ve описан. Возможно, это могло быть сделано, если передний веб-сервер (действующий как обратный прокси) мог бы установить нормальный сеанс HTTP и затем обновить его до https, не изменяя порты. Я думаю, что это поведение описано в RFC2817 (обновляющий до скручивания жгутов TLS HTTP/1.1), но i' m не уверенный, если nginx или другие веб-серверы знают, как иметь дело с тем стандартом. – alemartini 30 July 2009 в 06:54
-
2Я don' t имеют время для чтения целого RFC (и не верный i' m достаточно умный для понимания этого!), но Вы говорите о стандартном согласовании, прежде чем безопасная сессия будет установлена или полноценные различные сессии? Я думаю, что понимаю немного более - сервер служит на двух портах, и это - прокси, который относится, запрос - звучит прохладным, но я никогда не видел сделанный. Возможно, решение могло быть через создание единственного безопасного сайта на одном порте и наличии целого виртуального каталога, который просто наследовался / импортирует другой веб-сайт? Это doesn' t преобладают над всеми проблемами, но могут просто работать :S – William Hilsum 30 July 2009 в 07:14
Вы не можете поддерживать и HTTP и HTTPS по тому же порту, потому что оба конца соединения ожидают говорить определенный язык, и они не достаточно умны, чтобы удаться, говорит ли другой конец что-то еще.
Как Ваш комментарий к предложенному ответу Wil, Вы могли использовать обновление TLS (я полагаю, что более новые выпуски nginx поддерживают его, хотя я не попробовал), но это не выполняет HTTP и HTTPS, это просто выполняет HTTP с обновлением TLS. Проблемой является все еще поддержка браузера - большинство браузеров (все еще) не поддерживает ее. Если у Вас есть ограниченное объединение клиентов, то это - возможность, как бы то ни было.
-
1Зашифрованный и незашифрованный Трафик HTTP может быть обработан через единственный порт. Какой i' d нравится знать, то, если это возможно при помощи nginx или других продуктов (как lighttpd) действующий как обратные прокси. Вполне, вероятно, этот вид установки может быть обработан Apache, но я забыл упоминать в своем исходном вопросе это i' d скорее предпочитают не иметь необходимость использовать Apache (хотя i' d делают это если там isn' t любой другой выбор на платформе Linux для выполнения этого). – alemartini 30 July 2009 в 08:13
-
2Поскольку я сказал в своем ответе, " я верю более новой поддержке выпуска nginx [обновление TLS], хотя я haven' t tried". если Вам нужен я для чтения руководства для Вас, то you' ре не повезло. – womble♦ 31 July 2009 в 04:38
-
3I' m извините, если я произвел впечатление, что мне нужен кто-то для чтения руководства для меня. Просто кажется что проблема (и вопросы об этом) weren' t описанный достаточно точно (моя ошибка), ведя к различным интерпретациям того, что я спрашивал или необходимость. Таким образом, я решил открыть новый вопрос об этой проблеме и стараться избегать любого возможного беспорядка относительно проблемы или конкретных вопросов об этом. Так или иначе, спасибо за внимание и для совместного использования Вашего понимания. – alemartini 2 August 2009 в 00:30
Я не уверен, как это осуществляет его, но CUPSD отвечает и на http и на https на порте 631. Если nginx не может сделать этого теперь, возможно, они могут извлечь уроки из того, как команда CUPS осуществляет его, но CUPS находится под GPL, таким образом, nginx, вероятно, придется посмотреть на изменение его лицензии, если они действительно хотят реализовать такую возможность и не могут найти, что код делает так в другом месте.
Да, это возможно, но потребности, исправляющие nginx исходный код (HoverHell имеет решение, не исправляя). Nginx рассматривает это как неверную конфигурацию скорее затем действительная конфигурация.
Переменный $ssl_session_id может использоваться для отличия между плоскостью и ssl соединением.
Патч против 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)
Конфигурация сервера:
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;
}
Теоретически у вас может быть веб-страница, доступная через HTTP, которая может открывать WebSocket на https: 443 в любом месте, где захочет. Первоначальное рукопожатие WebSocket - это HTTP. Итак, да, можно сделать небезопасную страницу действительно способной к безопасному обмену данными. Это можно сделать с помощью библиотеки Netty .