Имитировать SSL-клиент в java

Question

У меня есть вопрос относительно клиента ssl в java. В случае браузера инициируется запрос приветствия клиента, который поддерживает номера шифров, номер версии и т. Д., И сервер отвечает сервером привет, имеющим набор шифров, который будет использоваться для этого сеанса.

Я думаю, что сеанс (jsessionId) создается в это время (сервер привет), если один не присутствует в клиенте привет (что означает jsessionId посылается клиенту незащищенного (?))

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

Если я должен сделать это в java, я могу использовать SSLSocket для установления рукопожатия и связать обработчик в методе addHandshakeCompletedListener.

Итак, после того, как рукопожатие завершено, управление приходит в addHandshakeCompletedListener метод обратного вызова.

Итак, если теперь мне нужно сделать запрос ssl, мне придется использовать HttpsURLConnection (?) И создать запрос.

Мой вопрос: -Как HttpsURLConnection знает о алгоритме шифрования и затем шифрует его с помощью этого?

Могу ли я сам его зашифровать, используя алгоритм шифрования в наборе шифров и опубликовать его через обычное http-соединение (HttpURLConnection (?)). Это будет работать?

Я знаю, что это сложная структура - нам нужно вычислить mac и затем добавить, прежде чем мы зашифруем данные. Делает ли это HttpsURLConnection?

Как работает сеанс? Как HttpsURLConnection знает, что это соединение уже было начато, а процедуры установления связи уже завершены?

Я не могу сопоставить все это? Любая помощь будет оценена! Если возможно, укажите пример для объяснения.

Answer 1

Так, если сейчас мне нужно сделать запрос Ssl мне придется использовать HttpsURLConnection (?) И создать запрос.

Мой вопрос: -Как HttpsURLConnection знает об алгоритме шифрования , а затем шифрует его?

Да, вы должны использовать HttpsURLConnection. Но вам не нужно делать это явно. new URL("https://google.pl").openConnection(); более чем достаточно.

В сервере Привет, сервер объявляет, какой encrypiton он может принять. Все методы шифрования должны «объявлять» себя, чтобы сервер знал, как их интерпретировать. Итак, когда вы инициируете соединение, серверы говорят, что он может обрабатывать, клиент выбирает один из циферперов и перебирает данные, используя его. В начале соединения клиент сообщает, какой пакет он будет использовать.

Эта информация может быть общедоступной, и это не является проблемой, поскольку это отправляется как открытый текст. Дело в том, что для обмена симметричным ключом между клиентом на сервере в частном порядке, так что остальная связь может быть зашифрована в этом ключе.

Как работает сессия? Как HttpsURLConnection знает, что это соединение уже было начато, а процедуры установления связи уже завершены ?

Хорошо SSL обозначает защищенный слой сокета. Это означает, что передача и получение данных шифруются, дешифруются на уровне сырых сокетов (потоков); Вы можете открыть SSL-соединение для передачи данных от точки к точке не только через Https

Нет сеанса. Пока вы открываете соединение, вы получаете 2 потока. Вход и выход. Пока они открыты, вы можете писать данные или читать их. Как только они будут закрыты, вам придется инициировать другое соединение.

Каждый запрос Http - это новое соединение (если только Keep-Alive не отправляется). Например, JsessionId или sessionid для php - это идентификация того, что вы тот же клиент, который ранее делал запросы, чтобы он мог «имитировать» постоянное соединение.

Answer 2

У меня есть вопрос относительно клиента ssl в java. В случае браузера инициируется запрос приветствия клиента с поддержкой наборов шифров, номером версии и т. Д., А сервер отвечает приветствием сервера, имеющим набор шифров, который будет использоваться для этого сеанса.

Исправить.

Я думаю, что сессия (JSessionID) создается в это время (сервер привет), если один не присутствует в клиенте привет (что означает JSessionID посылается клиенту незащищенного (?))

Нет Это часть HTTPS, а не SSL, и это происходит после того, как квитирование SSL завершено.

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

Исправить.

Если я должен сделать это в java, я могу использовать SSLSocket для выполнения рукопожатия и связать обработчик в методе addHandshakeCompletedListener.

Если вам нужно делать HTTPS на Java, то все, что вам нужно, это HttpsURLConnection. Вам также не нужен SSLSocket.

Итак, после того, как рукопожатие завершено, управление приходит в метод обратного вызова addHandshakeCompletedListener.

Это только с целью проверки идентичности сверстников, и этого не происходит в HttpsURLConnection.

Итак, если теперь мне нужно сделать запрос ssl, мне придется использовать HttpsURLConnection (?) И создать запрос.

Здесь вы должны начать. Все выше этого момента не имеет к вам никакого отношения.

Мой вопрос: -Как HttpsURLConnection знает о алгоритме шифрования и затем шифрует его с помощью этого?

Это не так. Он использует внутри себя SSLSocket, который делает все это.

Могу ли я сам его зашифровать, используя алгоритм шифрования в наборе шифров и опубликовать его через обычное http-соединение (HttpURLConnection (?)). Это будет работать?

Нет и нет. Ничего из этого не требуется. Все это сделано для вас.

Я знаю, что это сложная структура - нам нужно вычислить mac и затем добавить, прежде чем мы будем шифровать данные. HttpsURLConnection делает все это?

No, SSLSocket.

Как работает сессия?

Какая сессия? Есть два: сеанс SSL и сеанс HTTPS. Сеанс SSL поддерживается базовым SSLContext, сеансом HTTPS сервером через файл cookie jsessionid.

Как HttpsURLConnection знает, что это соединение уже было начато, а процедуры установления связи уже завершены?

Для этого используется SSLSocket.

Я не могу сопоставить все это? Любая помощь будет оценена! Если возможно, укажите пример для объяснения.

Слишком широкий.