https - как он должен работать?

Оказывается в HTML5 есть специальный элемент/тег - <keygen>

<form action="demo_keygen.htm" method="get">
Имя: <input type="text" name="usr_name">
Ключ: <keygen name="security">
<input type="submit">
</form>

Есть идея, что можно сделать два сайта - https://howto.mysite.ru и http://required.mysite.ru

На первом настроить просто https-соединение, чтобы пользователи могли создать себе ключ, отправить запрос на сайт и получить подписанный сайтом сертификат.

Потом перекидывать на второй сайт, на втором требовать сертификаты и не пускать без них.

Не нравится в этом процессе то, что определять, что открытое, что закрытое нужно будет не правами (например в файловвой системе), а размещением на одном из двух сайтов (что потребует изменения гиперссылок при перемещении гипертекста с одного сайта на другой при изменении прав)

TLS renegotiation (это то, что использует IIS и Apache для того, чтобы реализовать такой сценарий)

there is a first handshake where the server doesn't request a client certificate, followed by another handshake (encrypted this time) where the server requests the certificate (via a TLS CertificateRequest message)

Wireshark-у можно подсунуть закрытый ключ сервера, чтобы смотреть зашифрованный трафик

Осталось понять, как этот TLS CertificateRequest работает и как его затребовать из веб-приложения программно...

закрытое нужно будет не правами (например в файловвой системе), а размещением на одном из двух сайтов

Можно попробовать всё размещать на открытом, но проверять ACL и если прав не хватает, то делать клиентский редирект на страницу логина (а оттуда серверный, если получится, редирект обратно, ну или на страницу регистрации).

Тут проблема в том, как сделать обратно серверный редирект (не сбрасывая новую сессию), ведь страница логина должна находиться на другом URL, чтобы установилась новая сессия (и запрашивался бы клиентский сертификат).

Но вот как заставить его отправлять сертификат, когда его не спрашивают? Т.е. чтобы пользователи у которых сертификата нет,

видели бы просто сайт через зашифрованное соединение, а пользователи с сертификатами видели бы что-то своё особенное. Запрашивать сертификат, если аутентификация провалилась, то перенаправлять на особенное, не?

Запрашивать сертификат, если аутентификация провалилась

вот это непонятно как сделать.

проблема-то не в том, чтобы перенаправить на страницу регистрации,
а в том, чтобы выяснить - есть у пользователя в принципе клиентский сертификат или у пользователя сертификата нет, при этом не напрягая его по этому поводу с самого начала.

под особенным тут понимается не переход на регистрацию, а контент который доступен только после авторизации.

В первом и третьем случаях firefox работает как ожидается. А во втором - нет.

остальные браузеры работают? если нет, то проблема в сервере/сертификатах/настройках.

остальные браузеры работают?

chromium работает так же как firefox. Т.е. дело в моём конкретном непонимании протокола TLS и его использования для HTTP

Вроде для настройки tls не обязательно понимать все тонкости его работы, думаю дело в неправильной реализации опции на сервере, убедиться в этом можно при помощи wireshark, как сделано по твоей ссылке.

думаю ты не прав.

как по-твоему должна действовать правильная реализация?

проблема-то не в том, чтобы перенаправить на страницу регистрации,

а в том, чтобы выяснить - есть у пользователя в принципе клиентский сертификат или у пользователя сертификата нет, при этом не напрягая его по этому поводу с самого начала.

Когда я крайний раз играл с nginx, это было так:

1. у огнелиса нет сертификатов
2. огнелис коннектится к серверу
3. сервер просит сертификат
4. огнелис юзеру ничего не показывает
5. огнелис не даёт серверу сертификат
6. сервер посылает огнелису страницу с ошибкой 401
7. огнелис показывает страницу юзеру

1. у огнелиса есть сертификаты
2. огнелис коннектится к серверу
3. сервер просит сертификат
4. огнелис показывает юзеру диалог выбора сертификата
5. юзер выбирает неправильный сертификат
6. огнелис посылает серверу неправильный сертификат
7. сервер посылает огнелису страницу с ошибкой 401
8. огнелис показывает страницу юзеру

1. у огнелиса есть сертификаты
2. огнелис коннектится к серверу
3. сервер просит сертификат
4. огнелис показывает юзеру диалог выбора сертификата
5. юзер выбирает правильный сертификат
6. огнелис посылает серверу правильный сертификат
7. сервер посылает огнелису хорошую, годную страницу
8. огнелис показывает страницу юзеру

В твоём случае, я так понимаю, надо заменить страницу с ошибкой на свою, не?

В твоём случае, я так понимаю, надо заменить страницу с ошибкой на свою, не?

Тут нельзя обойтись одним маленьким советом, нужно описать полную правильную схему работы. Мне нужно такую:

1. файрфокс не имеет сертификата, приходит на страницу 2. сервер высылает серверный сертификат 3. файрфокс радуется, что соединение защищенное 4. сервер проверяет права доступа к странице в файловой системе 4.1. если права доступа для всех, то 4.1.1. сервер высылает страницу 4.1.2. файрфокс отображает страницу 4.1.3. пользователь видит, что он не залогинен 4.2. если права доступа для ограниченного круга лиц 4.2.1. сервер высылает запрос на клиентский сертификат 4.2.2. файрфокс показывает диалог выбора сертификата (а лучше каким-то образом сам определяет единственный сертификат используя для этого адрес сайта, там никаких для этого аддонов нет?) 4.2.3. файрфокс отсылает сертификат серверу 4.2.4. сервер проверяет валиден сертификат 4.2.4.1. если сертификат валиден, то сервер отсылает контент и информацию о пользователе 4.2.4.2. пользоатель видит, что он залогинен как эльф и радуется 4.2.5. если сертификат невалиден/отустствует, то 4.2.5.1. сервер перенаправляет пользователя на страницу регистрации 4.2.5.2. пользователь осознаёт как был не прав

Здесь важно то, что проверка в пункте 4 не может быть выполнена в web-сервере, так как там может быть сложная прикладная логика (проверка не только по файлововй системе, но и по другим источникам)

Есть два принципиальных решения - правильное и неработающее и неправильное, но работающее.

Неработающее - допилить web-сервер, чтобы появилась возможность управлять протоколом TLS из web-приложения

Работающее - управлять протоколом TLS косвенно, используя для этого всякие трюки в HTTP, такие как HTTP-result «moved temporarily», страницы с тегом meta refresh и тому подобное.

Неработающее - допилить web-сервер, чтобы появилась возможность управлять протоколом TLS из web-приложения

Назачем?

Работающее - управлять протоколом TLS косвенно, используя для этого всякие трюки в HTTP, такие как HTTP-result «moved temporarily», страницы с тегом meta refresh и тому подобное.

Не вижу причины, почему бы благородному дону так не сделать.

Если я правильно уловил, у тебя там есть веб-сервер и стоящее за ним приложение. Из веб-сервера высылаешь серверный сертификат и запрашиваешь клиентский. Потом в веб-сервере же валидируешь клиентский сертификат. В любом случае передаёшь запрос приложению, если сертификат валидный, в заголовках пишешь DN.

В приложении проверяешь указан ли DN. Если DN не указан, значит это анонимус. Если DN указан, значит регистрант, смотришь его права. Посылаешь ответ 200 или 400 или что там, в соответствии с правами.

Блджад, тревога.

Не вижу

вот, нет у тебя маркетингового видения. А мог бы придумать трейдмарк, запилить фреймворк и кричать на всех углах что твой подход круче чем новомодный OWIN.

Из веб-сервера высылаешь серверный сертификат и запрашиваешь клиентский.

Я не могу просто так запросить клиентский сертификат без повода. Потому что пользователю будет неудобно!

А тебе пользователи безразличны. В этом разница.

Я не могу просто так запросить клиентский сертификат без повода. Потому что пользователю будет неудобно!

Пользователю будет неудобно, если ты начнёшь на каждой странице запрашивать сертификат по новой. А так ты один раз запросил, он залогинился, все счастливы. Тебе нужен повод? Вот тебе повод: пользователь зашёл на сайт.

      Client                                               Server

      ClientHello                  -------->
                                                      ServerHello
                                                     Certificate*
                                               ServerKeyExchange*
                                              CertificateRequest*
                                   <--------      ServerHelloDone
      Certificate*
      ClientKeyExchange
      CertificateVerify*
      [ChangeCipherSpec]
      Finished                     -------->
                                               [ChangeCipherSpec]
                                   <--------             Finished
      Application Data             <------->     Application Data

             Fig. 1 - Message flow for a full handshake

   * Indicates optional or situation-dependent messages that are not
   always sent.

7.4.6. Client certificate

   When this message will be sent:
       This is the first message the client can send after receiving a
       server hello done message. This message is only sent if the
       server requests a certificate. If no suitable certificate is
       available, the client should send a certificate message
       containing no certificates. If client authentication is required
       by the server for the handshake to continue, it may respond with
       a fatal handshake failure alert. Client certificates are sent
       using the Certificate structure defined in Section 7.4.2.

т.е. сервер в этом режиме запрашивает сертификат как обычно, но не выдает ошибку, если сертификат клиентом не отправлен.

Вот тебе повод: пользователь зашёл на сайт.

это неправильный повод. На сайте могут быть закрытые и открытые страницы. Пользователь мог зайти на открытую страницу и тогда окажется, что сертификат будет спрошен по неправильному поводу (страница открытая, а сертификат спрашивают - нарушение прав и свобод пользователя).

правильный повод - это обращение к закрытой странице.