Помогите плиз с такой задачкой.
Нужно перевесит сайт с http на https (т.е. сделать доступ для ограниченного кол-ва пользователей)
Понимание что такое ssl и как он работает есть. Нет понимания как всё дело организовать.
читал вот здесь и здесь
но не до конца понял суть.
Скажите пожал как всё организовать чтобы в кач-ве сертиф.сервера выступала сторонняя организация.
И сколько в среднем по времени занимает времени от момента посыла запроса на перевод сайта на ssl (т.е. я понимаю, что сразу сертификат не выдается, нужно ждать время)?
я настраивал центр сертификации сам у себя и через него сам себе удостоверял запрос.
ждать надо ровно столько, сколько тебя заставят (когда сам, проще — тыкнул мышой и готово).
кроме того, насколько я понял, запрос "доверять ли этому сетификату" у клиента будет вылазить во всех случаях, если центром сертификации является самопальный "сервер". А не самопальные получается что вшиты в ie. Либо внутри домена можно как-то установить, что "доверять такому-то центру сертификации", но это я не знаю как.
S>И сколько в среднем по времени занимает времени от момента посыла запроса на перевод сайта на ssl
сайт переводится мгновенно — надо только сертификат получить.
Здравствуйте, Neco, Вы писали:
N>я настраивал центр сертификации сам у себя и через него сам себе удостоверял запрос. N>ждать надо ровно столько, сколько тебя заставят (когда сам, проще — тыкнул мышой и готово). N>кроме того, насколько я понял, запрос "доверять ли этому сетификату" у клиента будет вылазить во всех случаях, если центром сертификации является самопальный "сервер". А не самопальные получается что вшиты в ie. Либо внутри домена можно как-то установить, что "доверять такому-то центру сертификации", но это я не знаю как.
S>>И сколько в среднем по времени занимает времени от момента посыла запроса на перевод сайта на ssl N>сайт переводится мгновенно — надо только сертификат получить.
т.е. правильно ли я понял, что процедура такая (для общеизвестного сертиф сервера):
1. я делаю запрос на сертификат (но откуда делаю запрос c вэб сервера именно или с любого компа, а потом главное установить его?)
2. оплачиваю его
2. получаю сертификат
3. устанавливаю на web сервер
4. должен ли я высылать, что то клиентам (ключ, сертификат и т.п.)?
И если можно киньте пожалуйста проверенный сервер у которого лучше получить сертификат.
Спасибо!
Здравствуйте, Neco, Вы писали:
N>я настраивал центр сертификации сам у себя и через него сам себе удостоверял запрос. N>ждать надо ровно столько, сколько тебя заставят (когда сам, проще — тыкнул мышой и готово). N>кроме того, насколько я понял, запрос "доверять ли этому сетификату" у клиента будет вылазить во всех случаях, если центром сертификации является самопальный "сервер". А не самопальные получается что вшиты в ie. Либо внутри домена можно как-то установить, что "доверять такому-то центру сертификации", но это я не знаю как.
S>>И сколько в среднем по времени занимает времени от момента посыла запроса на перевод сайта на ssl N>сайт переводится мгновенно — надо только сертификат получить.
И еще один вопросик забыл. Как проще и лучше быть если просто нужно перевести на ssl, использовать свой сертиф сервер или использовать сторонний?
Здравствуйте, snaphold, Вы писали: S>т.е. правильно ли я понял, что процедура такая (для общеизвестного сертиф сервера): S>1. я делаю запрос на сертификат (но откуда делаю запрос c вэб сервера именно или с любого компа, а потом главное установить его?) S>2. оплачиваю его S>2. получаю сертификат S>3. устанавливаю на web сервер
Да. S>4. должен ли я высылать, что то клиентам (ключ, сертификат и т.п.)?
Ничего не надо. Всё это хэндлится протоколом HTTPS. Ну вот ты же пользовался им неоднократно — тебе хоть кто-то какие-то ключи высылал?
S>И если можно киньте пожалуйста проверенный сервер у которого лучше получить сертификат.
Не "сервер", а certification authority. Их — в ассортименте. Львиную долю рынка держит Verisign. Можешь посмотреть на Сomodo и GoDaddy. См. тж. http://en.wikipedia.org/wiki/Certificate_authority#Providers S>Спасибо!
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, snaphold, Вы писали: S>>т.е. правильно ли я понял, что процедура такая (для общеизвестного сертиф сервера): S>>1. я делаю запрос на сертификат (но откуда делаю запрос c вэб сервера именно или с любого компа, а потом главное установить его?) S>>2. оплачиваю его S>>2. получаю сертификат S>>3. устанавливаю на web сервер S>Да. S>>4. должен ли я высылать, что то клиентам (ключ, сертификат и т.п.)? S>Ничего не надо. Всё это хэндлится протоколом HTTPS. Ну вот ты же пользовался им неоднократно — тебе хоть кто-то какие-то ключи высылал?
S>>И если можно киньте пожалуйста проверенный сервер у которого лучше получить сертификат. S>Не "сервер", а certification authority. Их — в ассортименте. Львиную долю рынка держит Verisign. Можешь посмотреть на Сomodo и GoDaddy. См. тж. http://en.wikipedia.org/wiki/Certificate_authority#Providers S>>Спасибо!
А вот еще такой вопросик возник. У меня есть сервер с внешним айпи, но без доменного имени. Могу я получить сертификат на какое то доменное (сайты у меня есть) и кинуть его на этот бездоменный сайт?
Здравствуйте, snaphold, Вы писали: S>А вот еще такой вопросик возник. У меня есть сервер с внешним айпи, но без доменного имени. Могу я получить сертификат на какое то доменное (сайты у меня есть) и кинуть его на этот бездоменный сайт?
Можешь, но это ничему не поможет.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, snaphold, Вы писали: S>>А вот еще такой вопросик возник. У меня есть сервер с внешним айпи, но без доменного имени. Могу я получить сертификат на какое то доменное (сайты у меня есть) и кинуть его на этот бездоменный сайт? S>Можешь, но это ничему не поможет.
извините не совсем понял т.е. к сайту будет прикручен сертификат, но защиты не будет?
Здравствуйте, snaphold, Вы писали: S>извините не совсем понял т.е. к сайту будет прикручен сертификат, но защиты не будет?
Браузер будет ругаться на несоответствие сертификата доменному имени.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, snaphold, Вы писали: S>>извините не совсем понял т.е. к сайту будет прикручен сертификат, но защиты не будет? S>Браузер будет ругаться на несоответствие сертификата доменному имени.
Понял, спасибо! А открывать будет страницу или нет после ругания ?
Здравствуйте, snaphold, Вы писали: S>Понял, спасибо! А открывать будет страницу или нет после ругания ?
Если пользователь согласится, то да. Но ему будут настоятельно рекомендовать как можно быстрее уйти с нее.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, snaphold, Вы писали: S>>Понял, спасибо! А открывать будет страницу или нет после ругания ? S>Если пользователь согласится, то да. Но ему будут настоятельно рекомендовать как можно быстрее уйти с нее.
Возвращаясь к нашим баранам)) защита будет всё таки или нет, если сайт будет выдан на доменное имя, а прикручен будет к ip без домена?
Здравствуйте, snaphold, Вы писали:
S>>Если пользователь согласится, то да. Но ему будут настоятельно рекомендовать как можно быстрее уйти с нее. S>Возвращаясь к нашим баранам)) защита будет всё таки или нет, если сайт будет выдан на доменное имя, а прикручен будет к ip без домена?
Шифрование работать будет, проверка совпадения имени на которое выдан сертификат и реального имени сервера — отдаётся на совесть браузеру, а он обычно просто выдаёт предупреждение пользователю и просить решить — пользоваться дальше сайтом или нет, на что пользователь обычно не обращает внимания и спокойно пользуется дальше. Имя домена в процессе шифрования не участвует.
Вообще проверить это — дело пяти минут.
P.S. Интересно, а нельзя ли в IE 7 усилить политику SSL, чтобы всё же нельзя было пользоваться сайтами с неверными сертификатами?! Да и прогнать бы эту политику глобально через AD.
A>...проверка совпадения имени на которое выдан сертификат и реального имени сервера — отдаётся на совесть браузеру, а он обычно просто выдаёт предупреждение пользователю и просить решить — пользоваться дальше сайтом или нет, на что пользователь обычно не обращает внимания и спокойно пользуется дальше.
т.е я так понимаю, что опасность только для поьлзователя здесь, а именно в том, что его комп может общаться не с нужным сервером, а каким то другим. и следов он всё может прочитать?
A>Вообще проверить это — дело пяти минут.
А не скажите как?
A>P.S. Интересно, а нельзя ли в IE 7 усилить политику SSL, чтобы всё же нельзя было пользоваться сайтами с неверными сертификатами?! Да и прогнать бы эту политику глобально через AD.
А у меня клиенты вне моего домена. А сайт тоже вне домена и AD, но в подсети
Здравствуйте, snaphold, Вы писали:
S>т.е я так понимаю, что опасность только для поьлзователя здесь, а именно в том, что его комп может общаться не с нужным сервером, а каким то другим. и следов он всё может прочитать?
Да.
A>>Вообще проверить это — дело пяти минут. S>А не скажите как?
Включить на сервере SSL, и зайти на свой сайт, например, по IP (или можно ещё в hosts файлике прописать какой-нибудь левый хост на IP сервера и заходить по имени).
A>>P.S. Интересно, а нельзя ли в IE 7 усилить политику SSL, чтобы всё же нельзя было пользоваться сайтами с неверными сертификатами?! Да и прогнать бы эту политику глобально через AD.
S>А у меня клиенты вне моего домена. А сайт тоже вне домена и AD, но в подсети
Да это вопрос вслух, к твоему вопросу отношения не имеющий. Думаю было бы полезно совсем запретить ходить на неверные имена для пользователей корпоративной сети, как средство и против злоумышленников, так и против нерадивых администраторов внутри самой сети.
А еще такой вопрос, если я буду использовать асимметричные алгоритмы (с закрытым ключом), то мне при появлении нового клиента как и где получить новый закрытый ключ? Запрос на сертификат к сертиф серверу?
Если Да, то мне кажется мне лучше подойдет свой сертиф сервер, тем более у меня только ip. Верно?
Здравствуйте, snaphold, Вы писали:
S>А еще такой вопрос, если я буду использовать асимметричные алгоритмы (с закрытым ключом), то мне при появлении нового клиента как и где получить новый закрытый ключ? Запрос на сертификат к сертиф серверу?
В случае SSL, тебе делать ничего не придётся — достаточно установить на сервере сертификат, а уж клиент сам разберётся, что и как ему шифровать.
(Или ты уже ведёшь речь о клиентских сертификатах и аутентификации через них?)
Здравствуйте, Andir, Вы писали:
A>Здравствуйте, snaphold, Вы писали:
S>>А еще такой вопрос, если я буду использовать асимметричные алгоритмы (с закрытым ключом), то мне при появлении нового клиента как и где получить новый закрытый ключ? Запрос на сертификат к сертиф серверу?
A>В случае SSL, тебе делать ничего не придётся — достаточно установить на сервере сертификат, а уж клиент сам разберётся, что и как ему шифровать.
A>(Или ты уже ведёшь речь о клиентских сертификатах и аутентификации через них?)
A>C Уважением, Andir!
У меня теперь каша в голове
поясните пожалуста.
В моем понимании сейчас картина такая. Есть клиентские сертификаты и обычные. Клиентские используют закрытый ключ (всегда) и у каждого клиента свой сертиф для аутенфикации. Если появляется новый клиент, то он не сможет зайти если ему не выдать сертификат
А обычные сертиф, это с открытым ключом и сертификат только на сервере, у клиента ничего нет, просто при входе на сервер идет сопоставление сертификата и сервера. И клиенту не нужно иметь сертификата, IIS сервера шифрует данные и без клиента, единств, если как я писал выше, опасность может быть для клиента, если он не обратит внимание на предупреждения браузера, что сертиф может быть выдан одному домену, а прикручен к левому ip или другому и тогда велика вероятность того, что кто-то что-то перехватывает.
Здравствуйте, snaphold, Вы писали:
S>Всё верно я представляю?
Представляешь верно, но только перемешал всё вместе.
Итак: SSL — это дополнительный слой, используемый протоколом https для того чтобы зашифровать сообщения HTTP-протокола перед отправкой их через небезопасную сеть (TCP), сообщения шифруются симметричным шифром, ассиметричное шифрование используется только для генерирования сессионных ключей симметричного шифрования.
Происходит это всё следующим образом:
1) клиент обращается к серверу по протоколу https: (далее уже SSL),
2) сервер и клиент договаривются об используемых функциях шифрования,
3) сервер отсылает клиенту свой открытый ключ (он содержится в сертификате),
4) клиент генерирует некоторый предварительный секрет (зависит от используемых алгоритмов),
5) сервер и клиент на основе этого секрета и псевдослучаных последовательностей генерируют общий сессионный ключ.
6) генерируется сессионной ключ симметричного шифрования (используя мини-протокол выработки общего секрета путём шифрования ассиметричным ключами псевдослучайных последовательностей и предварительного секрета).
7) далее идёт обмен данными с использованием симметричного шифрования и выработанного ключа.
О сертификатах:
Сертификат сервера — используется для аутентификации сервера клиентом и для предварительного обмена информацией (безопасное получение сессионного ключа). Браузеры аутентификацию сервера проделывают путём сравнения имени хоста с именем указанным в сертификате, и если оно не совпадает то перекладывают аутентификацию на плечи пользователя выводя предупреждение (это всё, конечно, в случае, если сертификат сервера выпущен CA которому доверяет сервер). После того как пройдена аутентификация начинается протокол выработки сессионного ключа (как я описал выше).
Клиентские сертификаты же — это лишь способ аутентификации клиента сервером, — альтернатива использованию логина/пароля. То есть наличие у клиента сертификата, подлинность которого может проверить сервер — это лишь способ опознать текущего пользователя. Но работает это совместно с SSL, во время этапа когда сервер отсылает свой сертификат клиенту, он может также запросить сертификат клиента, чтобы его аутентифицировать ("может" определяется настройками сервера).
Соответственно шифрование косвенно привязано только к серверному сертификату, по клиентскому сертификату — сервер опознаёт клиента и далее может применять какие-либо авторизационные политики, выдавая 403-статус (например: не пускать совсем; запрещать доступ к определённым ресурсам; скрывать информацию от пользователя не имеющего необходимых прав).
c вэб сервера именно или с любого компа, а потом главное установить его?)
?
