Браузер не будет делать накладной запрос к CA, чтобы узнать, не отозван ли серт веб-сервера — вместо этого твой веб-сервер (если в нём поддерживается OSCP Stapling) периодически делает такие запросы к CA, а на этапе TLS-рукопожатия отдаёт браузеру подписанный выдавшим сертификат центром сертификации ответ о том, не отозван ли серт.
А не проще ли традиционную связку имя-пароль разместить и не заморачиваться? Если пользователь ввёл имя и/или пароль неправильно, код проверки подлинности просто сообщит что-то наподобие.
Вы ввели неправильное имя пользователя или пароль.
И никакие данные не утекут. Единственное, может быть использована форма регистрации для проверки, зарегистрирована ли уже почта, но как-то можно снизить эту угрозу, думаю, с помощью капчи, например.
прежде чем обратиться к серверу, клиент посылает сообщение KDC, а KDC в свою очередь направляет каждому участнику сеанса копии сеансового ключа, действующие в течение небольшого промежутка времени.
Всё-таки KDC (TGS) не контактирует с двумя сторонами, когда клиент запрашивает соединение.
Клиент (принципал), чтобы проийти взаимную проверку подлинности с запрашиваемым ресурсом, отправляет запрос TGS-REQ в сторону TGS. В этом запросе содержатся TGT клиента и наименование запрашиваемого ресурса (servicePrincipalName, например, как и у вас в статье). TGS возвращает клиенту в ответ TGS-REP, в котором содержатся служебный билет и сеансовый ключ для сеанса между клиентом и ресурсом. А уж потом клиент делает запрос к ресурсу с этим билетом, в ходе которого клиент и ресурс проходят взаимную проверку подлинности.
TGS незачем что-то передавать ресурсу — всё есть в TGS-REP, и это довольно экономичное решение с точки зрения количества передаваемых данных.
А статья полезная. Лет 7 назад как подумывал об использовании Kerberos для OTRS, никогда руки не доходили.
Я не совсем понимаю, а искусственная и защищённая от наклонов площадка посреди океана не может выступать в качестве «твердой земли»? Ставят же неподвижные буровые платформы в открытом море.
На сколько я помню, говорилось, что у него не очень радужные перспективы с его нынешним телом.
You have to understand that I don't really have many choices… If I don't try this chance my fate will be very sad. With every year my state is getting worse.
Так что трансплантация тела была бы хоть какой-то надеждой на спасение.
Чтобы читающего не смутило обобщение, надо отметить, что есть много случаев, когда при работе даже с core-моудлями за идемпотентностью следит пользователь, например, это касается модуля replace, где пользователю требуется внести изменение так, чтобы при повторном проигрывании той же самой игры однажды изменённая строка вдруг опять не дала положительной реакции и не привела к очередному изменению.
Браузер не будет делать накладной запрос к CA, чтобы узнать, не отозван ли серт веб-сервера — вместо этого твой веб-сервер (если в нём поддерживается OSCP Stapling) периодически делает такие запросы к CA, а на этапе TLS-рукопожатия отдаёт браузеру подписанный выдавшим сертификат центром сертификации ответ о том, не отозван ли серт.
Как настроить — www.digicert.com/enabling-ocsp-stapling.htm
И никакие данные не утекут. Единственное, может быть использована форма регистрации для проверки, зарегистрирована ли уже почта, но как-то можно снизить эту угрозу, думаю, с помощью капчи, например.
Вообще же, раз на то пошло, лучше.
Всё-таки KDC (TGS) не контактирует с двумя сторонами, когда клиент запрашивает соединение.
Клиент (принципал), чтобы проийти взаимную проверку подлинности с запрашиваемым ресурсом, отправляет запрос TGS-REQ в сторону TGS. В этом запросе содержатся TGT клиента и наименование запрашиваемого ресурса (servicePrincipalName, например, как и у вас в статье). TGS возвращает клиенту в ответ TGS-REP, в котором содержатся служебный билет и сеансовый ключ для сеанса между клиентом и ресурсом. А уж потом клиент делает запрос к ресурсу с этим билетом, в ходе которого клиент и ресурс проходят взаимную проверку подлинности.
TGS незачем что-то передавать ресурсу — всё есть в TGS-REP, и это довольно экономичное решение с точки зрения количества передаваемых данных.
А статья полезная. Лет 7 назад как подумывал об использовании Kerberos для OTRS, никогда руки не доходили.
Так что трансплантация тела была бы хоть какой-то надеждой на спасение.
Нужно отметить, что если права суперпользователя нужны для выполнения всех задач в игре, то можно просто указать ключ sudo на уровне игры:
Или в файле ansible.cfg. Или в качестве ключа в командной строке.
throwиспользовать.cast — приводить, casting соотв. — приведение.