Хабрахабр

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

Массачусетский Технологический институт. Курс лекций #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

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

Итак, сегодня мы поговорим о том, как интернет использует криптографию для защиты сетевого соединения, и рассмотрим две тесно связанные темы.

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

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

Её смысл в том, что у вас есть секретный ключ K и две функции. В последней лекции о Kerberos мы использовали симметричную криптографию, или
шифрование и дешифрование. И если вы зашифруете этот простой текст, вы получите зашифрованный текст С. Таким образом, вы можете взять некоторый фрагмент данных, назовем его P, это обычный текст, к которому можно применить функцию шифрования, а это функция некоторого ключа K. Это тот примитив, вокруг которого был построен Kerberos. Точно также у нас есть функция расшифровки D, которая использует тот же ключ K, в результате чего зашифрованный текст C превратится в простой текст P.

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

Для того, чтобы его расшифровать функцией D, нужно просто указать соответствующий секретный ключ sk и получить исходный текст P. Здесь есть функция E, которая может зашифровать определенным открытым ключом pk некую совокупность сообщений P, чтобы в результате получить зашифрованный текст C.

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

Например, вы можете подписать сообщение M вашим секретным ключом sk и получить какую-то подпись S. Оказывается, что на уровне реализации это связанные операции, но на уровне приложений API они могут выглядеть немного иначе. Затем вы можете верифицировать это сообщение с помощью соответствующего открытого ключа pk и в результате получить логический флаг, сообщающий, является ли подпись S правильной для сообщения M.

Если вы, например, получили эту подпись и она верифицируется корректно, значит, она должна была быть сгенерирована кем-то с правильным секретным ключом. Здесь присутствуют некоторые относительно интуитивные гарантии, которые обеспечивают эти функции. Это понятно?

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

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

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

Возможно, люди в MIT готовы доверять кому-то в локальной сети, управляемой KDC, но не всем в Интернете.

На самом деле может быть очень трудно построить единственный KDC, который сможет управлять миллиардом ключей или десятью миллиардами ключей для всех людей в мире. И ответ второго студента тоже верный – очень сложно управлять таким гигантским количеством ключей. Вы даже не сможете использовать Kerberos в нашем институте для подключения к некоторым серверам, если у вас нет учетной записи в базе данных Kerberos. Ещё одна сложность использования Kerberos для всего интернета заключается в том, что все пользователи должны иметь ключ, или должны быть известны KDC. В то время как для всего интернета вполне разумно ожидать, что когда вы подойдете к компьютеру, то он совершенно не знает, кто вы, но позволит вам перейти на сайт Amazon, защищенный криптографией.

Да?

Но идея ключа заключается в том, что это решение совершено одинаково и для Kerberos, и для SSL или TLS. Существует несколько других вещей, которые вы ожидаете от криптографического протокола, и мы рассмотрим, как они появляются в SSL. И если мы хотим использовать их для современного интернета, то в них понадобится кое-что изменить. Вы правы, когда упоминаете, что исходные протоколы Kerberos, о которых мы прочитали в материалах лекции, разработаны очень давно. Какие ещё у вас имеются мысли, почему мы не должны использовать Kerberos?

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

Студент: сервер Kerberos постоянно должен быть онлайн.

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

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

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

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

У вас есть А и В, они хотят общаться, и А знает открытый ключ В. Таким образом, типичный протокол может выглядеть так. Затем А собирается отправить B сеансовый ключ S, так что это похоже на Kerberos. При этом А генерирует какой-то сессионный ключ S, просто выбирая для него случайное число. Мы собираемся зашифровать сеансовый ключ S для B.

Но с публичным ключом вы можете проделать это сразу, просто зашифровав секрет с помощью этого открытого ключа Bspk, и отправить сообщение B. Если помните, в Kerberos, чтобы сделать это, нам был нужен KDC, потому что А не знал ключа для B или ему не было позволено его знать, потому что это секрет, который может знать только B. Теперь мы имеем канал связи, где все сообщения просто шифруются этим секретным ключом S. Теперь B может расшифровать это сообщение и сказать: мне нужно использовать этот секретный ключ.

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

Поэтому В должен имеет соответствующий секретный ключ S. Еще одна хорошая вещь — это уверенность в том, что сообщения, отправляемые от А к В, сможет прочитать только В, потому что только В может расшифровать это сообщение.

Студент: имеет ли значение, кто даёт этот ключ — пользователь или сервер?

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

Студент: атакующий может использовать ключ для отправки повторных сообщений?

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

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

Есть два числа и ключ, который на самом деле не выбирается единолично одной стороной, это хэш, который выбрали обе стороны для совместного взаимодействия. Обычно случается так, что одна сторона выбирает случайное число вроде S, а затем другая сторона, В, также выбирает случайное число, обычно называемое nonce. Это более сложная математика, чем простое хеширование двух случайных чисел, которые выбрали эти две стороны. Кроме хеша, можно использовать протокол Диффи-Хэллмана, который мы рассматривали в последней лекции, благодаря которому вы получаете секретность вначале. Но тогда вы получите такое хорошее свойство, как изначальный общий секретный ключ, исключающий необходимость передачи ключа расшифровки при передаче зашифрованных данных.

В генерирует nonce и затем устанавливает настоящий секретный ключ S’, который используется для хеширования секретного ключа S с этим nonce. Таким образом, избежать повторные атаки можно следующим образом. И, конечно, В должен был бы отправить nonce обратно A, чтобы выяснить, что происходит, когда они оба договариваются о ключе.

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

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

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

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

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

Однако основой для всего вышесказанного является то, что все стороны знают открытые ключи друг друга. Это проблемы, которые достаточно просто исправляются на уровне протокола. Допустим, я хочу подключиться к веб-сайту, у меня есть URL-адрес, к которому я хочу подключиться, или имя хоста, как мне узнать, какой публичный ключ ему соответствует? Как же вы можете узнать чей-то публичный ключ?

Аналогично, если я подключаюсь к серверу MIT, чтобы посмотреть мои оценки, откуда сервер знает, каким должен быть мой открытый ключ, чтобы отличить его от открытого ключа другого студента MIT?

Фактически KDC решал для нас две проблемы. Это главная проблема, которую рассматривал KDC. Сейчас мы исправили это, создав криптографию с открытым ключом. Во-первых, он генерировал сообщение (Ebspk (S)), создавал сеансовый ключ и шифровал его для сервера. Но нам также нужно было выполнить сопоставление главных строковых имен криптографическим ключам Kerberos, предоставленным нам ранее.

Его смысл заключается в том, что мы по-прежнему будем полагаться на некоторые стороны процесса, поддерживающие эти гигантские таблицы, которые сопоставляют имена участников процесса с криптографическими ключами. Для подобных вещей в мире HTTPS имеется протокол TLC. Этот CA также логически поддерживает таблицу, в одной части которой отображаются имена всех участников, а в другой – соответствующие им публичные ключи. План состоит в том, что у нас будет нечто, называемое центром сертификации, который обозначается буквами CA во всех видах литературы по сетевой безопасности. Вместо этого в мире CA поступают таким образом. Главное отличие этого центра от Kerberos состоит в том, что этот центр сертификации CA не обязательно должен находиться онлайн для всех транзакций.
В Kerberos для того, чтобы соединиться с кем-то или найти чей-то ключ, вам нужно поговорить с KDC.

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

Так что если у вас есть запись «имя+ключ» в базе данных CA, то CA создаст сообщение, что это имя соответствует этому открытому ключу, и подпишет это сообщение своим секретным ключом CA.

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

Сервер, с которым вы хотите поговорить, хранит сертификат, который он первоначально получил от центра сертификации. Это работает так. Он был подписан этим CA. И всякий раз, когда вы подключаетесь к нему, сервер говорит вам: «хорошо, вот мой сертификат. Вы можете проверить подпись и просто убедиться, что это мой открытый ключ, и что это мое имя».

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

Студент: где работает регистратор, у которого можно получить сертификат аутентификации?

В какой-то момент вам нужно жестко закодировать их, это, как правило, то, что делает большинство систем. Профессор: да, это как вопрос типа того, что было раньше – курица или яйцо, или где вы получаете эти открытые ключи? Их существует огромное количество. Когда вы загружаете веб-браузер или получаете компьютер в первый раз, он фактически приходит с сотнями открытых ключей этих центров сертификации. US Postal Service по некоторым причинам тоже имеет свой CA, так как существует множество сетевых сущностей, которые участвуют в системе и которым нужно выдать на это сертификат. Некоторые управляются такими компаниями по сетевой безопасности, как VeriSign. Таким образом, множество CA формируют доверие, которое мы бы имели в единственном KDC.

Так, мы не рассмотрели вопрос, как миллиарды людей в мире смогут доверять единственному компьютеру KDC. Собственно говоря, фактически мы не рассмотрели все проблемы, связанные с Kerberos. Любой из них может подписать сообщение подобного типа, и оно было бы принято клиентами как правильное утверждение того, что этот участник системы имеет этот открытый ключ. Однако на самом деле сейчас ситуация ещё хуже, потому что вместо доверия одной машине KDC, теперь все доверяют этим сотням центров аутентификации, потому что все они равноценны друг другу. Так что теперь злоумышленнику будет достаточно взломать только один из этих CA вместо того, чтобы взламывать KDS.

Студент: есть ли механизм для отзыва ключей?

Как известно, если вы облажались, то можете сказать KDC, чтобы он перестал выдавать ваш ключ или заменил его новым. Профессор: да, это еще одна проблема. С одной стороны, предполагается, что эти сертификаты имеют время действия. Но сертификаты действительны вечно, поэтому типичное решение двояко. Это вроде как время жизни билета Kerberos, только на несколько порядков длительнее. Таким образом, вы можете, по крайней мере, ограничить ущерб. Таким образом, СА действительно не хотят, чтобы с ними общались слишком часто. В Kerberos время жизни билета может быть пару часов, а сертификат действует год или пару лет. Это хорошо для масштабируемости, но не хорошо для безопасности. Так что вы платите деньги, получаете годовой сертификат в виде кучки подписанных байтов, и обращаетесь за ними снова только через год.

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

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

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

Во-первых, они постарались опубликовать список всех отозванных в мире сертификатов под названием CRL, Сertificate Revocation List. Существуют две альтернативы, которыми люди пытались воспользоваться. Каждый центр аутентификации ведёт список выданных сертификатов, помечая где-то в стороне ошибки, связанные с этими сертификатами. Это работает таким образом. Так что сообщи всему миру, что мой сертификат больше не годится». Например, он выясняет, что выдал сертификат не на то имя, или к нему обращается клиент и говорит: «эй, ты выдал мне сертификат, все шло отлично, но потом кто-то взломал мой компьютер и украл приватный ключ.

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

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

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

В мире CA отошли от этой практики и решили, что СА будет подписывать сертификаты только раз в год. Вторая альтернатива заключается в том, чтобы люди смогли посылать запросы СА онлайн, так же, как это происходит в мире Kerberos, где мы постоянно связываемся с KDC. Этот протокол отталкивает нас от мира CA к миру KDC. Поэтому существует альтернативный протокол, называемый «онлайн протоколом проверки статуса SSL сертификатов», или OCSP. Так вот, используя протокол OCSP, вы можете связаться с сервером и просто сказать: «эй, я получил этот сертификат. Всякий раз, когда клиент получает сертификат, ему интересно, является ли этот сертификат действительным, ведь несмотря на то, что его срок действия ещё не истёк, что-то всё равно могло пойти не так. Таким образом, этот протокол просто перекладывает обязанность поддерживать CRL на определенный сервер. Как вы думаете, это все еще в силе»? Это еще один план, который люди попытались использовать, но он также не получил широкого распространения по двум причинам. Поэтому вместо того, чтобы загружать весь список самостоятельно, вы попросите сервер проверить этот сертификат.

26:30 мин

Лекция 14: «SSL и HTTPS», часть 2 Курс 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 не будет опубликован. Обязательные поля помечены *

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