Не уверен, как это сделать в C #, но это можно сделать в Java, используя SSLEngine
.Этот API обычно считается довольно сложным для программирования.Так что, да, возможно использовать асинхронные сокеты для SSL / TLS, но я не уверен, какой будет эквивалент SSLEngine
в Java.Возможно, есть другой (лучший?) API для этого в C #.
Есть несколько проблем, с которыми вы почти неизбежно столкнетесь на этом пути (основываясь на опыте Java, но это применимо аналогичным образом в C #):
В то время как SSLSocket
s, как правило, справляются со своей задачей, ведя себя подобно обычным Socket
s, существуют небольшие крайние случаи из-за природы SSL / TLS.Влияние этих различий еще более важно при асинхронном вводе / выводе.Некоторые из этих проблем описаны в этом (довольно длинном) ответе на "Правильное закрытие SSLSocket" (в Java) .
Кроме того, некоторые поведения SSL / TLS уже плохо определены суважение к прикладному уровню, и немного запутаться с асинхронным поведением.Я имею в виду пересмотр сертификата клиента (или пересмотр в целом) в виду.Используя SSL / TLS, любая из сторон может в принципе инициировать повторное согласование.Это делается, например, если вы защищаете только один каталог с клиентскими сертификатами в Apache Httpd или если только часть веб-приложения требует CLIENT-CERT
в контейнере Java.При использовании проверки подлинности на основе сертификата клиента даже IIS по умолчанию использует повторное включение.Это состоит из второго рукопожатия во время соединения SSL / TLS (фактически, чтобы получить больше информации от клиента здесь: его клиент-сертификат).
Когда это работает (обычно с блокированием ввода / вывода), трафиквыглядит следующим образом (здесь слои SSL
и HTTP
):
C->S SSL Client Hello
S->C SSL Server Hello, Certificate, Server Hello Done
C->S SSL Client Key Exchange, Change Cipher Spec, Finished
S->C SSL Change Cipher Spec
(then encrypted)
C->S SSL Finished
C->S HTTP GET /.../
S->C SSL Hello Request
C->S SSL Client Hello
S->C SSL Server Hello, Certificate, Certificate Request, Server Hello Done
C->S SSL Certificate, Client Key Exchange, Certificate Verify, Change Cipher
Spec, Finished
S->C SSL Change Cipher Spec
C->S SSL Finished
S->C HTTP 200 OK
Повторное согласование в асинхронном режиме довольно сложно, поскольку повторное согласование должно применяться к обеим сторонам трафика нав то же время.Следовательно, базовые свойства сеанса SSL / TLS могут измениться во время его использования прикладным уровнем (который обычно не обрабатывает это).Одна сторона все еще может отправлять данные, предполагая определенные настройки SSL / TLS, в то время как происходит повторное согласование, затрагивая тем самым обе стороны.
Реализация всего этого может быть трудной, как показано в этой проблеме Grizzly, например.