Хабрахабр

[Перевод] Курс MIT «Безопасность компьютерных систем». Лекция 14: «SSL и HTTPS», часть 2

Массачусетский Технологический институт. Курс лекций #6.858. «Безопасность компьютерных систем». Николай Зельдович, Джеймс Микенс. 2014 год

Computer Systems Security — это курс о разработке и внедрении защищенных компьютерных систем. Лекции охватывают модели угроз, атаки, которые ставят под угрозу безопасность, и методы обеспечения безопасности на основе последних научных работ. Темы включают в себя безопасность операционной системы (ОС), возможности, управление потоками информации, языковую безопасность, сетевые протоколы, аппаратную защиту и безопасность в веб-приложениях.

Лекция 1: «Вступление: модели угроз» Часть 1 / Часть 2 / Часть 3
Лекция 2: «Контроль хакерских атак» Часть 1 / Часть 2 / Часть 3
Лекция 3: «Переполнение буфера: эксплойты и защита» Часть 1 / Часть 2 / Часть 3
Лекция 4: «Разделение привилегий» Часть 1 / Часть 2 / Часть 3
Лекция 5: «Откуда берутся ошибки систем безопасности» Часть 1 / Часть 2
Лекция 6: «Возможности» Часть 1 / Часть 2 / Часть 3
Лекция 7: «Песочница Native Client» Часть 1 / Часть 2 / Часть 3
Лекция 8: «Модель сетевой безопасности» Часть 1 / Часть 2 / Часть 3
Лекция 9: «Безопасность Web-приложений» Часть 1 / Часть 2 / Часть 3
Лекция 10: «Символьное выполнение» Часть 1 / Часть 2 / Часть 3
Лекция 11: «Язык программирования Ur/Web» Часть 1 / Часть 2 / Часть 3
Лекция 12: «Сетевая безопасность» Часть 1 / Часть 2 / Часть 3
Лекция 13: «Сетевые протоколы» Часть 1 / Часть 2 / Часть 3
Лекция 14: «SSL и HTTPS» Часть 1 / Часть 2 / Часть 3

Каждый раз, когда вы хотите подключиться к серверу, вам сначала нужно подключиться к OCSP, подождать, пока он ответит, а затем сделать что-то еще. Первая причина заключается в том, что протокол OCSP добавляет задержку к каждому запросу, который вы делаете. Так что задержки соединения отнюдь не способствуют популярности этого протокола.

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

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

Так что использование OCSP не слишком хороший план. Клиент скажет так: «я пытаюсь запросить проверку сертификата нужного мне сайта, но этого OCSP, кажется, нет рядом, так что я просто зайду на этот сайт».

Так, например, веб-браузер Chrome поставляется клиенту, уже имея внутри себя список сертификатов, которые Google действительно хочет отозвать. На практике люди стараются создать этому альтернативу, потому что клиенты просто склонны совершать тяжёлые ошибки. Таким образом, вам не придется обращаться к серверу CRL и общаться с OCSP. Так если кто-то неправильно выдает сертификат для Gmail или другого важного сайта, например, Facebook или Amazon, то следующая версия Chrome уже будет содержать эти сведения во встроенном списке верификации. Если браузер проверил, что сертификат больше не действителен, клиент его отвергает.

Студент: допустим, я украл секретный ключ сертификата CА, ведь не все открытые ключи зашифрованы?

Я не думаю, что есть какое-либо решение этой проблемы. Профессор: да, это будет иметь плохие последствия. Не совсем понятно, как это произошло, возможно, кто-то действительно украл их секретный ключ. Конечно, были ситуации, когда центры сертификации оказывались скомпрометированы, например, в 2011 году было два скомпрометированных CА, которые каким-то обманным образом выдавали сертификаты для Gmail, Facebook и так далее. Но не зависимо от причин компрометации, эти CА были удалены из списка доверенных центров сертификации, который встроен в браузеры, так что в следующем выпуске Chrome их уже не было.

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

Они лучше Kerberos в том смысле, что вам больше не нужно, чтобы этот парень всё время был в интернете. Итак, мы рассмотрели общий принцип действия сертификатов. К тому же они более масштабируемы, потому что вы можете иметь несколько KDC и при этом вам не нужно с ними общаться при каждой установке соединения.

Вы можете подключиться к веб-серверу, не имея для себя сертификата, и такое происходит постоянно. Еще одна интересная особенность этого протокола в том, что в отличие от Kerberos, вы не обязаны проводить проверку подлинности обеих сторон соединения. Таким образом, на уровне протокола шифрования у вас нет сертификата, а у Amazon он имеется. Если вы заходите на amazon.com, то собираетесь проверить, что Amazon — это правильный сайт, но Amazon понятия не имеет, кто вы, и не будет об этом знать, пока вы не совершите аутентификацию на сайте.

Единственное неудобство использования этого протокола состоит в том, что сервер обязательно должен иметь сертификат. Это гораздо лучше, чем Kerberos, потому что там для подключения к сервисам Kerberos у вас заранее должна иметься запись в его базе данных. Я понятия не имею, кто ты, а ты понятия не имеешь, кто я, но давай все равно это зашифруем». Так что вы не можете подключиться к серверу и сказать: «эй, давай просто зашифруем наши вещи. Вы можете зашифровать с кем-то общие вещи, при этом его не зная, тогда злоумышленник, готовящийся вас атаковать, точно также может позже зашифровать свои пакеты и защититься этим от слежки. Это называется оппортунистическим шифрованием, и конечно, оно уязвимо для атак типа «человек посередине».

Но такова жизнь. Так что немного жаль, что эти протоколы, которые мы здесь рассматриваем — SSL, TLS — не предлагают такого рода оппортунистического шифрования.

Скажем так, раз в год, они создают пары ключей с новыми именами. Студент: мне просто любопытно. Почему бы не попробовать использовать этот конкретный ключ целый год?

Но похоже, что с этой схемой что-то идет не так. Профессор: я думаю, они так и поступают. Компьютеры становятся быстрее, разрабатываются новые алгоритмы, которые успешно взламывают это шифрование. Здесь, как и в случае Kerberos, люди начинают с использования надёжного шифрования, но со временем оно становится все хуже и хуже. Так, например, происходит в случае, когда подписывается огромное количество сертификатов. И если люди не заботятся о повышении надёжности, проблемы растут.

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

Возможно, 20 лет назад MD5 был хорош, но со временем люди обнаружили в нём слабые места, которые могут быть использованы злоумышленником. Проблема возникла потому, что люди использовали MD5 в качестве хэш-функции, превращая подписание огромного сообщения в вещь размером 128 бит, которая подвергалась шифрованию.

В результате у него оказалась хэшированная подпись СА, а затем появилось другое сообщение, или другой ключ, или другое имя, и теперь он может убедить кого-то, что оно подписано правильным сертификатом. Предположим, в какой-то момент кто-то действительно попросил сертификат с конкретным хешем MD5, а затем тщательно разобрал другое сообщение, которое было хэшировано тем же значением MD5. Например, если вы проводите много времени, пытаясь взломать один ключ, вы в конце концов достигнете успеха. И такое действительно происходит. Если этот сертификат использует шифрование, его можно взломать методом brute-force.

Мы не говорили об RSA, но RSA является одной из этих криптографических систем с открытым ключом, которая позволяет шифровать и подписывать сообщения. Еще один пример неудачного использования шифрования – это алгоритм RSA. Вам, вероятно, придется проделать гигантский объём работы, но подобное легко выполняется в течение года. В наши дни можно потратить много денег, но, в конце концов, взломать 1000-битные ключи RSA. Можно попросить центр сертификации подписать какое-либо сообщение или даже взять чей-то существующий открытый ключ, попробовать подобрать к нему соответствующий секретный ключ, либо взломать вручную.
Таким образом, вы должны идти в ногу со злоумышленником, вы должны использовать ключи RSA большего размера или же использовать другую схему шифрования.

Они используют алгоритм криптографического хеширования SHA-1. Например, сейчас люди не используют хэши MD5 и сертификаты. Сейчас Google активно пытается заставить веб-разработчиков и разработчиков браузеров отказаться от использования SHA-1 и использовать другую хэш-функцию, потому что вполне ясно, что, возможно, через 5 или 10 лет успешно атаковать SHA-1 не составит никакого труда. Какое-то время он обеспечивал необходимую безопасность, но на сегодня это слабая защита. Его слабость уже была доказана.

Вы просто должны убедиться, что продолжаете развиваться параллельно с хакерами. Так что, полагаю, волшебной пули как таковой не существует. Поэтому все вещи, о которых мы говорили, должны основываться на правильном шифровании, либо на том, что его очень трудно взломать. Безусловно, проблема существует. По крайней мере, здесь имеется срок годности, так что лучше выберем параметры срока годности 1 год, а не 10 лет. Поэтому вы должны выбрать подходящие параметры.

Поэтому вам стоит выбрать более агрессивные параметры безопасности, например, 4000 или 6000 битные ключи RSA, или что-то еще. Вот этот ключ CAs создаёт более серьёзную проблему, так как не имеет обязательного срока годности. Или другую схему шифрования, или всё вместе, но не используйте здесь SHA-1.

Если вы хотите обеспечить сетевое общение или связь с сайтами с помощью криптографии, в браузере существуют три вещи, которые мы должны защищать. А теперь давайте посмотрим, как мы интегрируем этот протокол в конкретное приложение, а именно в веб-браузер.

Это сравнительно легко, потому что мы просто собираемся запустить протокол, очень похожий на тот, что я описывал до сих пор. Первая вещь, А – это защита данных в сети. Вот как мы будем защищать данные. Мы зашифруем все сообщения, подпишем их, убедимся, что они не были подделаны, в общем, проделаем все эти замечательные вещи.

Так, первая, В – это код, который используется в браузере, например, JavaScript или важные данные, которые хранятся в браузере, ваши кукиз, или локальное хранилище, все это должно быть как-то защищено от хакеров. Но есть еще две вещи в веб-браузере, о которых нам действительно стоит побеспокоиться. Через секунду я расскажу, как их надо защищать.

И причина этого в том, что, в конечном счете, большая часть конфиденциальных данных, о защите которых мы заботимся, поступает от пользователя. Последнее, С, о чём вы часто не задумываетесь, но что может оказаться реальной проблемой на практике — это защита пользовательского интерфейса. Так, пользователь печатает данные на каком-то сайте, и он, вероятно, имеет несколько одновременно открытых вкладок разных сайтов, поэтому нужно, чтобы он мог различать, с каким сайтом он фактически взаимодействует, причём в любой момент времени.

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

Как я уже упоминал, для защиты данных в сети мы просто будем использовать этот протокол, называемый SSL или TLS, если используется шифрование и проверка подлинности данных. Итак, давайте поговорим о том, как поступают с этими вещами A, B и С современные браузеры.

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

Он не прошел проверку подлинности по сети. Так что если у нас есть какой-то незашифрованный код JavaScript, работающий в нашем браузере, мы должны предположить, что он мог быть подделан злоумышленником, потому что не был зашифрован. И, следовательно, мы должны предотвратить его вмешательство с любой страницы, которая была доставлена через незашифрованное соединение.

Вы часто видите это в URL-адресах. Таким образом, общий план состоит в том, что для этого мы собираемся ввести новую схему URL, которую назовём HTTPS. Так что если у вас есть URL с этим HTTPS://, то он имеет другой источник происхождения origin, нежели обычные URL-адреса HTTP, потому что последние проходят незашифрованные исправления, они идут через SSL/TLS. Новая схема URL заключается в том, что теперь эти URL-адреса просто отличаются от HTTP-адресов. Таким образом, вы никогда не спутаете эти типы адресов, если одна и та же политика происхождения работает правильно.

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

На самом деле получается так, что центры сертификации собираются подписать имя хоста, которое появляется в URL как имя открытого ключа веб-сервера. План заключается в том, что имя хоста через URL должно быть именем в сертификате. Это имя в нашей таблице, которое имеет открытый ключ, соответствующий их секретному ключу. Таким образом, Amazon предположительно имеет сертификат для www.amazon.com.

Так что если он получает сертификат, если он пытается подключиться или получить URL-адрес foo.com, это означает, что сервер точно представляет подлинный сертификат foo.com. Это то, что будет искать браузер. Это будет несоответствие сертификатов. В противном случае, скажем, мы пытались связаться с одним парнем, а связались с другим, потому что у него в сертификате совсем другое имя, к которому мы подключились.

Так что это часть той же политики origin, согласно которой мы разделяем код на части. Вот как мы будем отличать разные сайты друг от друга: мы привлечём к этому CA, чтобы они помогли нам отличить эти сайты друг от друга, потому что CA обещают выдавать сертификаты только правильным участникам сети. Они почти что такого же origin, но не совсем, у кукиз немного другой план. Как вы помните, кукиз имеют несколько иную политику. Правило состоит в том, что если кукиз имеет такой флаг, то они отправляются только в ответ на запросы HTTPS или вместе с запросами HTTPS. Кукиз имеют так называемый флаг безопасности, Secure Flag. Кукиз с флагом безопасности и без такого флага соотносятся друг с другом как запросы https и http.

Было бы проще, если бы кукиз просто указывало, что это cookie для хоста HTTPS, а это cookie для хоста HTTP, и они совершенно разные. Это немного сложно. К сожалению, по историческим причинам, кукиз используют этот странный вид взаимодействия. Это было бы предельно ясно с точки зрения изоляции безопасных сайтов от небезопасных.

Безопасные файлы cookie применяются только к URL-адресам узлов HTTPS, а небезопасные – для обоих видов адресов, как для https, так и для http, поэтому буквально через секунду это станет для нас источником проблем. Поэтому, если файл cookie помечен как безопасный, он применяется только к HTTPS-сайтам, то есть у него правильный хост.

Таким образом, вы должны обращать внимание на значок замка в адресной строке браузера и на URL-адрес, чтобы выяснить, на каком сайте вы действительно находитесь. И последний штрих, который наносят веб-браузеры, чтобы попытаться помочь нам в этом плане — это аспект пользовательского интерфейса, в котором они собираются ввести какой-то значок блокировки, чтобы его видели пользователи.

Таков аспект пользовательского интерфейса браузера. Разработчики веб-браузеров ожидают, что вы будете себя вести именно так: попав на какой-то сайт, вы сначала посмотрите на URL-адрес и убедитесь, что это именно то имя хоста, с которым вы хотите поговорить, а затем найдёте значок замка и поймёте, что всё хорошо.

Оказывается, многие фишинговые сайты будут просто включать изображение значка замка в сам сайт, но при этом использовать другой URL. Однако этого недостаточно. В этом смысле эта сторона пользовательского интерфейса немного запутана, отчасти потому, что сами пользователи часто путаются. И если вы не знаете, каков должен быть адрес настоящего сайта, вас могут обмануть. Поэтому мы сосредоточимся в основном на втором аспекте, В, который точно гораздо проще обсудить. Так что трудно сказать, что здесь правильно. Есть вопросы по этому поводу?

Студент: я заметил, что некоторые сайты со временем превращаются из HTTP в HTTPS.

Некоторые браузеры устанавливают значок блокировки, только если все содержимое или все ресурсы вашей страницы также передаются через https. Профессор: да, браузеры со временем развиваются, и это подтверждается тем, что они получают значок блокировки. Поэтому иногда вы не сможете получить значок блокировки из-за этой проверки. Так что одна из проблем, которую HTTPS пытается решить принудительно, это смешанное содержание или проблемы небезопасных видов контента, встроенного в страницу. Однако разные браузеры поступают по-разному, и если Chrome не даст вам значок блокировки, то Firefox может дать. Если браузер Chrome считает, что сертификат сайта недостаточно хорош и использует слабую криптографию, то он не даст вам значок блокировки. Таким образом, опять же, нет четкого определения того, что означает этот значок блокировки.

В обычном HTTP мы привыкли полагаться на DNS, который должен дать нам правильный IP-адрес на сервере. Давайте посмотрим, какие проблемы могут возникнуть при реализации этого плана. Заслуживают ли DNS серверы доверия или для нас более важно сопоставление DNS? Насколько мы должны доверять DNS в предоставлении этих HTTPS URL-адресов?

Студент: я думаю, должны доверять, потому что сертификат подписывает доменное имя, а не IP-адрес.

Профессор: совершенно верно, сертификат подписывает доменное имя, такое, как amazon.com.

Студент: предположим, кто-то украдёт приватный ключ amazon.com, свяжет его с другим сервером и другим IP-адресом.

Итак, DNS сам по себе достаточно деликатная вещь, поэтому нужно заботиться о его безопасности. Профессор: совершенно верно, вы говорите о том, что возможно оба случая – когда кто-то украдёт приватный ключ и перенаправит DNS на себя. Но что произойдёт, если кто-то взломает DNS-сервер и укажет нам другой IP-адрес? Вы правы в том, что DNS нужен для того, чтобы определить нужный нам IP-адрес, иначе можно потерять хост. Насколько это плохо?

Студент: может быть, он просто скомпрометирует HTTPS?

Профессор: в принципе, это опасно, потому что в таком случае браузер вообще может отказаться от установки соединения.

Студент: нет, хакер просто перенаправит вас на HTTP URL.

Профессор: дело в том, что если вы подключаетесь к сайту по HTTPS, они не могут перенаправить вас на незащищённый сайт.

Студент: вы можете подписать свой сертификат и попытаться обмануть пользователя.

Вы можете попытаться использовать другой сертификат. Профессор: да, это правда. Это возможно, если вы скомпрометировали CA, или просто подписали свой собственный сертификат, или, может быть, у вас есть какой-то старый сертификат того парня, у которого вы раздобыли секретный ключ.

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

Возможно, они просто забывают обновить свои сертификаты. Но исторически HTTPS внедрялся так, что операторы веб-серверов неправильно его настраивали. Однако подобное не устраивает разработчиков веб-браузеров. Все шло отлично, вы не заметили, что срок действия вашего сертификата истёк, и просто забыли его продлить. Поэтому они предлагают пользователю диалоговое окно, в котором указывают, что сертификат у данного сайта есть, но он выглядит как-то неправильно, однако вы всё равно можете продолжать работать с данным сайтом. «Это просто просроченный сертификат, так что давайте позволим пользователю его использовать». Таким образом, веб-браузеры как бы позволяют пользователям отменять действующие правила относительно срока действия сертификатов.

Например, вы можете подключиться к amazon.com или www.amazon.com, или, возможно, к другому имени хоста. Так же поступают с именами хостов, потому что, возможно, ваш сайт имеет несколько правильных имён.

В этом случае пользователь задумывается, говоря себе: „ну да, имя хоста выглядит не совсем правильно, но, возможно, я всё равно сюда зайду». Если вы недостаточно осторожны как веб-оператор, то можете даже не знать, что вам нужно получить сертификаты для всех возможных имён, которые имеет ваш сайт. Так что в определённой степени такое право выбора тоже становится проблемой безопасности. В этом состоит причина, почему веб-браузеры предоставляют пользователям возможность принимать более широкий диапазон сертификатов, чем диктуют правила.

В этом случае, если вы захватили DNS, то могли бы перенаправить пользователя на один из этих сайтов с неправильным сертификатом, и если пользователь не будет осторожен и его браузер примет такой сертификат, то у него будут проблемы.

Конечно, вы не захотите предоставить произвольным пользователям контроль над вашим DNS-именем, но целью SSL / TLS и HTTPS, является не доверять DNS вообще. Таким образом, вопрос, насколько вы должны действительно доверять DNS, остаётся открытым. У вас не должно быть возможности подвергнуться DoS атаке, или перехвату ваших данных, их повреждению и так далее. Если здесь все работает корректно, значит DNS доверять не стоит.

Мы говорили, что если пользователь принимает сертификат от неправильного хоста или сертификат с истекшим сроком действия, что при этом может пойти не так? Ещё один интересный вопрос, о котором нужно поговорить — это как можно атаковать пользователя, который неправильно утверждает сертификат? О чём мы должны побеспокоиться, если пользователь совершает ошибки такого рода?

Таким образом, злоумышленники могут прикрываться именем пользователя. Студент: например, он может совершать какие-то действия не на том сайте, который намеревался посетить.

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

Студент: я думаю, что хакер может получить все кукиз пользователя и использовать их в своих целях.

Это может оказать на вас более продолжительное влияние. Профессор: точно, вот этого следует опасаться. Поэтому, если вы подключаетесь к веб-серверу злоумышленников и просто принимаете их сертификат для amazon.com за реальную вещь, то браузер будет думать, что сущность, с которой он говорит, и есть настоящий amazon.com. Причина, по которой это срабатывает, заключается в том, что браузер, принимая решение о том, кому разрешено получить определенный набор cookies, а кому не разрешено, просто смотрит на имя хоста в URL-адресе, к которому вы должны были быть подключены, и руководствуется политикой origin. Поэтому он будет относиться к нему, как к настоящему серверу amazon.com, а это означает, что этот сервер должен получить доступ ко всем кукиз, которые у вас есть для этого хоста, и предположительно, по тому же принципу одинакового происхождения, он разрешит запустить чужой код JavaScript в вашем браузере.

Затем вы закрываете свой ноутбук и открываете его в другом месте, чтобы продолжить пользоваться сайтом. Возможно, у вас в браузере открыта вкладка, подключённая к реальному веб-сайту. Если вы одобрите его, то хакер сможет получить доступ к старой странице amazon.com, которая открыта в вашем браузере, и браузер посчитает, что это имеет то же самое происхождение, потому что страницы имеют одинаковое имя хоста. В этот момент кто-то перехватывает ваше соединение с amazon.com и «впрыскивает» свой ответ. Так что если пользователь делает неправильный выбор, утвердив чужой неправильный сертификат, он имеет шанс подвергнуться подобной атаке. Это будет довольно проблематично.

52:10 мин

Лекция 14: «SSL и HTTPS», часть 3 Курс MIT «Безопасность компьютерных систем».

Полная версия курса доступна здесь.

Вам нравятся наши статьи? Спасибо, что остаётесь с нами. Поддержите нас оформив заказ или порекомендовав знакомым, 30% скидка для пользователей Хабра на уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps от $20 или как правильно делить сервер? Хотите видеть больше интересных материалов? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps до декабря бесплатно при оплате на срок от полугода, заказать можно тут.

класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки? Dell R730xd в 2 раза дешевле? Только у нас 2 х Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 ТВ от $249 в Нидерландах и США! Читайте о том Как построить инфраструктуру корп.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть