forum.opennet.ru - "Шифрование https ssl" (4)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"Шифрование https ssl"

Форум Информационная безопасность (Шифрование, SSH, SSL)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Шифрование https ssl"	+/–
Сообщение от krnprogmail.ru (ok) on 10-Ноя-15, 18:30
Добрый день. Никак не могу разобраться в следующем вопросе. У нас есть web сервер, работающий по протоколу https. Протокол https реализован посредством самоподписанного ssl сертификата. Вопрос: при доступе клиента к серверу по протоколу https шифрование данных обеспечивается в обе стороны (от клиента к серверу и от сервера к клиенту) или только от клиента к серверу? Вопрос возник по какой причине: для шифрования по https нужны 2 ключа - закрытый и открытый. Закрытый лежит в недоступном хранилище, открытый, соответственно в публичном доступе. Клиент подключаясь получает публичный ключ, которым шифрует данные. Сервер, соответственно, при получении данных расшифровывает их с помощью закрытого ключа. Тут все ясно. Как обстоят дела с данным, передаваемыми от сервера к клиенту? Чем их шифровать? Никаких других сертификатов нет. Даже если предположить, что они будут зашифрованы с помощью закрытого ключа, то любой желающий сможет их спокойно расшифровать т.к. открытый ключ в публичном доступе. Вот и возник вопрос, а шифруются ли они вообще?
Ответить \| Правка \| Cообщить модератору

Оглавление

Шифрование https ssl, eRIC, 19:34 , 10-Ноя-15, (1) +3

Шифрование https ssl, krnprogmail.ru, 20:09 , 10-Ноя-15, (2)

Шифрование https ssl, eRIC, 21:36 , 10-Ноя-15, (3) +1

Шифрование https ssl, уги, 01:00 , 01-Апр-16, (7)

Сообщения по теме [Сортировка по ответам | RSS]

1. "Шифрование https ssl" +3 +/–

Сообщение от eRIC (ok) on 10-Ноя-15, 19:34

коллега не забывайте что стороне клиента так же генерируется некий рандомный симметричный шифр K(называют по разному но в основном session key), которое шифруется публичном ключем сервера и передается серверу. далее сервер используя свой закрытый ключ расшифровывает этот ключ K. т.е. этот ключ знают ТОЛЬКО клиент и сервер в рамках сессии HTTPS и которое далее используется для шифрования и расшифровывания сообщений. клиент шифрует данные при помощи К, сервер расшифровывает данные от клиента. когда сервер отправляет данные то он шифрует его с К, а клиент расшифровывает его
а так получается, если судить по вашей теории: что любой может публичным ключем сервера шифровать(потому что он доступный), так как сервер всегда будет его расшифровывать удачно потому что на сервере закрытый ключ. должна же быть некая изюминка, которая участвует только между этими двумя о которой знают только обе стороны :)
кратко говоря используются Симметричное шифрование данных внутри Асимметричного шифрования, мясорубка %)

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Шифрование https ssl" +/–

Сообщение от krnprogmail.ru (ok) on 10-Ноя-15, 20:09

>[оверквотинг удален]
> шифрования и расшифровывания сообщений. клиент шифрует данные при помощи К, сервер
> расшифровывает данные от клиента. когда сервер отправляет данные то он шифрует
> его с К, а клиент расшифровывает его
> а так получается, если судить по вашей теории: что любой может публичным
> ключем сервера шифровать(потому что он доступный), так как сервер всегда будет
> его расшифровывать удачно потому что на сервере закрытый ключ. должна же
> быть некая изюминка, которая участвует только между этими двумя о которой
> знают только обе стороны :)
> кратко говоря используются Симметричное шифрование данных внутри Асимметричного шифрования,
> мясорубка %)
И можно быть уверенным в том, что любой WEB браузер или любое другое приложение, взаимодействующее с сервером через https генерирует свой session key? Т.е. это необходимое требование для взаимодействия по данному протоколу и если оно не будет выполнено взаимодействия просто не будет?

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Шифрование https ssl" +1 +/–

Сообщение от eRIC (ok) on 10-Ноя-15, 21:36

> И можно быть уверенным в том, что любой WEB браузер или любое
> другое приложение, взаимодействующее с сервером через https генерирует свой session key?
> Т.е. это необходимое требование для взаимодействия по данному протоколу и если
> оно не будет выполнено взаимодействия просто не будет?
на этом принципе и работают все, на то и стандарты. применимо не только для https, но других протоколах где задействовано SSL/TLS. марш читать книжки на ночь
для начала:
https://en.wikipedia.org/wiki/Transport_Layer_Security
https://en.wikipedia.org/wiki/Public-key_cryptography
и добавок не путайте схожие по названию но разные понятия типа PHPSESSIONID, JSESSIONID и т.д. в веб приложениях с "session key" в сеансе TLS

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

7. "Шифрование https ssl" +/–

Сообщение от уги on 01-Апр-16, 01:00

При наличии бесплатных сертификатов от Let's Encrypt[1] и WoSign[2] использовать само-подписанную - не очень разумно и чревато MITM.
Как Вам уже сказали - шифруется все, но правильно настраивать веб сервер для надежного TLS нужно еще уметь, если что - проверяйте как у Вас получилось настроить безопасность сервера по этим ссылкам [3][4].
[1] https://letsencrypt.org/
[2] https://buy.wosign.com/free/
[3] https://www.ssllabs.com/ssltest/
[4] https://securityheaders.io/

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру


	1. "Шифрование https ssl"	+3 +/–
	Сообщение от eRIC (ok) on 10-Ноя-15, 19:34
	коллега не забывайте что стороне клиента так же генерируется некий рандомный симметричный шифр K(называют по разному но в основном session key), которое шифруется публичном ключем сервера и передается серверу. далее сервер используя свой закрытый ключ расшифровывает этот ключ K. т.е. этот ключ знают ТОЛЬКО клиент и сервер в рамках сессии HTTPS и которое далее используется для шифрования и расшифровывания сообщений. клиент шифрует данные при помощи К, сервер расшифровывает данные от клиента. когда сервер отправляет данные то он шифрует его с К, а клиент расшифровывает его а так получается, если судить по вашей теории: что любой может публичным ключем сервера шифровать(потому что он доступный), так как сервер всегда будет его расшифровывать удачно потому что на сервере закрытый ключ. должна же быть некая изюминка, которая участвует только между этими двумя о которой знают только обе стороны :) кратко говоря используются Симметричное шифрование данных внутри Асимметричного шифрования, мясорубка %)
	Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	2. "Шифрование https ssl"	+/–
	Сообщение от krnprogmail.ru (ok) on 10-Ноя-15, 20:09
	>[оверквотинг удален] > шифрования и расшифровывания сообщений. клиент шифрует данные при помощи К, сервер > расшифровывает данные от клиента. когда сервер отправляет данные то он шифрует > его с К, а клиент расшифровывает его > а так получается, если судить по вашей теории: что любой может публичным > ключем сервера шифровать(потому что он доступный), так как сервер всегда будет > его расшифровывать удачно потому что на сервере закрытый ключ. должна же > быть некая изюминка, которая участвует только между этими двумя о которой > знают только обе стороны :) > кратко говоря используются Симметричное шифрование данных внутри Асимметричного шифрования, > мясорубка %) И можно быть уверенным в том, что любой WEB браузер или любое другое приложение, взаимодействующее с сервером через https генерирует свой session key? Т.е. это необходимое требование для взаимодействия по данному протоколу и если оно не будет выполнено взаимодействия просто не будет?
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	3. "Шифрование https ssl"	+1 +/–
	Сообщение от eRIC (ok) on 10-Ноя-15, 21:36
	> И можно быть уверенным в том, что любой WEB браузер или любое > другое приложение, взаимодействующее с сервером через https генерирует свой session key? > Т.е. это необходимое требование для взаимодействия по данному протоколу и если > оно не будет выполнено взаимодействия просто не будет? на этом принципе и работают все, на то и стандарты. применимо не только для https, но других протоколах где задействовано SSL/TLS. марш читать книжки на ночь для начала: https://en.wikipedia.org/wiki/Transport_Layer_Security https://en.wikipedia.org/wiki/Public-key_cryptography и добавок не путайте схожие по названию но разные понятия типа PHPSESSIONID, JSESSIONID и т.д. в веб приложениях с "session key" в сеансе TLS
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	7. "Шифрование https ssl"	+/–
	Сообщение от уги on 01-Апр-16, 01:00
	При наличии бесплатных сертификатов от Let's Encrypt[1] и WoSign[2] использовать само-подписанную - не очень разумно и чревато MITM. Как Вам уже сказали - шифруется все, но правильно настраивать веб сервер для надежного TLS нужно еще уметь, если что - проверяйте как у Вас получилось настроить безопасность сервера по этим ссылкам [3][4]. [1] https://letsencrypt.org/ [2] https://buy.wosign.com/free/ [3] https://www.ssllabs.com/ssltest/ [4] https://securityheaders.io/
	Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору