Это дополнительный вопрос к "SSL-подтверждение с использованием самостоятельных Подписанные сертификаты и SSLEngine (JSSE)".
Я реализовал веб-сервер NIO, который может обрабатывать сообщения SSL и не-SSL на одном и том же порту. Чтобы различать сообщения SSL и не-SSL, я проверяю первый байт входящего запроса, чтобы убедиться, что это сообщение SSL/TLS. Пример:
byte a = read(buf);
if (totalBytesRead==1 && (a>19 && a<25)){
parseTLS(buf);
}
В методе parseTLS() я создаю экземпляр SSLEngine, инициирую рукопожатие, обертываю/разворачиваю сообщения и т. д. Кажется, что все работает нормально для большинства современных веб-браузеров (Firefox 10, IE 9, Safari 5 и т. д.).
Проблема в том, что более старые веб-браузеры, такие как IE 6, и библиотеки, такие как класс Java URLConnection, похоже, по-разному инициируют рукопожатие SSL/TLS. Например, первые несколько байтов из IE 6 выглядят примерно так (шестнадцатеричные значения):
80 4F 01 03 00 ...
Если я передам сообщение SSLEngine, он, похоже, не распознает сообщение и выдаст исключение.
javax.net.ssl.SSLException: Unsupported record version Unknown-0.0
Итак, что именно пересылает класс IE 6 и Java URLConnection? Является ли это действительным сообщением SSL/TLS, которое может поддерживать JSSE SSLEngine? Должен ли я выполнять предварительную обработку или договариваться с клиентом, чтобы отправить другое сообщение?
Заранее спасибо!
ОБНОВЛЕНИЕ
Благодаря Bruno и EJP, а также дальнейшей отладке, я лучше понимаю, что происходит. Как правильно заметил Бруно, клиенты IE6 и Java 6 отправляют через SSLv2 ClientHello. Вопреки одному из моих предыдущих комментариев, SSLEngine в Java 1.6 фактически может развернуть сообщение SSLv2 и сгенерировать допустимый ответ для отправки обратно клиенту. SSLException, о котором я сообщал ранее, был ошибкой на моей стороне и не имеет ничего общего с SSLEngine (я неправильно предположил, что клиент завершил отправку данных, и в итоге я получил пустой ByteBuffer, когда SSLEngine ожидал больше данных для развертывания).
