Оффлайн
- Регистрация
- 12.05.16
- Сообщения
- 1.927
- Реакции
- 523
- Репутация
- 0
SSL и TLS используют все криптографические технологии, которые мы уже прошли, включая симметричные и асимметричные алгоритмы, хеши, цифровые подписи, коды аутентификации сообщений (MAC), для создания рабочего протокола обеспечения безопасности. SSL и TLS - это криптографические протоколы, созданные для обеспечения безопасности коммуникаций в сети или в Интернете.
SSL - это более старый протокол шифрования, а TLS более новый, однако люди до сих пор называют их одним названием - SSL, что немного раздражает и вводит в заблуждение. Множество сайтов по-прежнему используют старый SSL из-за вопросов совместимости, даже при условии, что из-за этого возникают проблемы в безопасности.
Примером использования TLS является HTTPS в URL-адресе веб-сайта, как, например, здесь. Но TLS может быть использован с любым другим протоколом типа FTP или в виртуальных частных сетях. Он используется не только с HTTP и не только для работы с веб-сайтами. TLS очень важен для безопасности и приватности в Интернете, поскольку это наиболее часто используемый способ шифрования данных в Интернете. TLS обеспечивает приватность, потому что с его помощью шифруются данные, и обеспечивает целостность, потому что он использует имитовставки, то есть коды аутентификации сообщений (MAC), во время обмена данными между двумя приложениями.
Например, когда ваш веб-браузер, приложение, обменивается данными с вашим интернет-банком, их приложением, коммуникация шифруется по принципу end-to-end от вашего приложения до их приложения при помощи TLS.
TLS поддерживает средства защиты конфиденциальности или приватности, аутентификации и целостности. Соединение приватно, потому что симметричный алгоритм, например AES, который мы обсуждали, используется для шифрования передаваемых данных. Ключи для этого симметричного шифрования генерируются уникальным образом для каждого соединения, и они основаны на секретном ключе, согласованном в начале сеанса.
Сервер и клиент согласовывают детали, какой алгоритм шифрования и криптографические ключи они будут использовать перед тем, как первый байт данных будет отправлен. Согласование совместно используемого секретного ключа не может быть считано злоумышленником, даже атакующим, находящимся посередине соединения. Соединение также надежно в том, что атакующий не может модифицировать коммуникацию во время согласования и при этом остаться незамеченным.
Идентификационные данные лиц, обменивающихся данными, могут быть аутентифицированы при помощи криптографии с открытым ключом, сертификатов и цифровых подписей. Подобная аутентификация может использоваться по усмотрению, но в целом она обязательна для как минимум одной стороны, обычно для сервера, то есть веб-сайтов, которые вы посещаете. И я расскажу вам больше на эту тему, когда мы доберемся до сертификатов.
Соединение надежно, потому что каждое передаваемое сообщение проходит проверку целостности сообщения при помощи кодов аутентификации сообщений (MAC) с целью предотвращения невыявленной потери или изменения данных в процессе их передачи.
TLS поддерживает множество различных способов по обмену ключами, шифрованию данных и аутентификации целостности сообщений, многие из тех алгоритмов и технологий, которые мы уже обсуждали. И все же, в конечном итоге, безопасная конфигурация TLS включает в себя множество настраиваемых параметров, и не все из них позволяют использовать средства защиты приватности, аутентификации и целостности.
Лучше всего использовать Диффи-Хеллмана с эфемерными ключами — RSA (с прямой секретностью), либо Диффи-Хеллмана на эллиптических кривых с эфемерными ключами — RSA (с прямой секретностью), или же Диффи-Хеллмана на эллиптических кривых с эфемерными ключами — алгоритм цифровых подписей на основе эллиптических кривых ECDSA (с прямой секретностью). В общем-то, проблема в том, что у вас и выбор-то не всегда есть. Сервер поддерживает определенные аутентификацию и методы согласования ключей, и если вы хотите обмениваться с ним данными, то вам придется использовать то, что он предлагает. Причина, по которой лучше использовать эти способы, в том, что они используют протокол Диффи-Хеллмана для обмена ключами, что позволяет обеспечить такое свойство приватности, как "прямая секретность", здесь это указано.
Это свойство дает гарантию, что ваши сеансовые ключи не будут скомпрометированы, даже если закрытый ключ сервера скомпрометирован. Это достигается тем, что уникальный сеансовый ключ генерируется для каждой сессии, которую пользователь инициирует. Даже компрометация единичного сеансового ключа не повлияет ни на какие данные, за исключением того обмена в том определенном сеансе, который защищался конкретно этим ключом.
Совершенная прямая секретность - это прогресс в вопросах по защите данных на транспортном уровне. Ее значимость увеличилась с момента появления таких уязвимостей, как Heartbleed. Итак, совершенная прямая секретность на деле означает, что если сервер, с которым вы общаетесь, скомпрометирован, и их закрытый ключ скомпрометирован, то все ваши предыдущие сеансы общения не могут быть дешифрованы, поскольку вы использовали протокол Диффи-Хеллмана для согласования сеансовых ключей, а они используются лишь в течение короткого промежутка времени.
Если мы спустимся ниже, то увидим используемые симметричные алгоритмы. Когда мы говорим о сеансовых ключах, то мы имеем ввиду ключи, которые используются непосредственно для шифрования данных, потому что симметричные ключи быстрее. И помните, мы говорили об AES, что выбор AES - это хороший вариант? В этой таблице мы видим его и различные другие виды алгоритмов симметричного шифрования.
Нам показано, какие из них защищенные, а какие нет, по причине различного рода уязвимостей или слабых мест, и вот почему я рекомендовал вам использовать AES. 10
Здесь вы можете заметить, что есть какие-то другие аббревиатуры в комбинации с AES. Вам не нужно особо волноваться на этот счет. Это называется "режимом использования". Это различные способы для AES по скремблированию или шифрованию данных, которые не имеют особого значения в нашем случае для предмета нашего обсуждения. Достаточно знать, что вы используете AES и длину в битах, мы уже разобрались в этом вопросе.
Здесь вы также можете увидеть различные версии SSL. Собственно говоря, и это приводит многих людей в замешательство, первая версия SSL - это 2.0, самая ранняя версия из всех представленных в этой таблице, следующая версия - это SSL 3.0, далее идет TLS 1.0 Обратите внимание, следом за тройкой для SSL идет единица для TLS. Итак, TLS 1.3 - это самая последняя и наиболее защищенная версия, но она наименее совместима с браузерами. Когда вы используете TLS, вам реально стоит использовать TLS 1.0 или выше. Видим здесь, какие из них защищенные, а какие нет. Обратите внимание, что если вы используете TLS 1.0, то даже несмотря на AES, тут указано "Зависит от воздействия".
Давайте спустимся еще ниже. Здесь мы видим хеши, а также имито-вставки (MAC), которые используются с целью сохранения целостности данных. MD5 не стоит использовать, SHA1 определенно уже устарел, и нам стоит начать использовать актуальные версии SHA, а именно 256 и 384. Однако по причинам совместимости, они могут быть использованы не во всех случаях.
Можете погуглить на этот счет и поискать детали, если интересно, а результатом всего этого стало то, что разработчикам пришлось обновлять браузеры и серверные реализации SSL, чтобы справиться с атаками и защититься от этих уязвимостей. Перейдем к следующей таблице, здесь мы видим список версий Firefox. В этой строке Firefox версий с 27-й по 33-ю. И вы можете увидеть уязвимости Beast, Crime, Poodle, Freak, Logjam. А если мы посмотрим на версии от 36-й до 38-й, то они подвержены уязвимости Logjam. Если будем смотреть на все более старые версии, то увидим, что они становятся все более и более подверженными различным слабостям и уязвимостям, вот почему вам следует использовать самую последнюю версию браузера, где это возможно. Серверы и сайты, на которые вы заходите, также должны быть обновлены до последних версий.
И все дело в том, что вы не можете всегда контролировать это. И если вам нужна приватность, максимальная приватность, и вы знаете, что ваш сервер не защищен, либо уязвим перед некоторыми из этих вещей, поскольку он, возможно, использует TLS 1.0, то вы должны понимать, что нельзя взаимодействовать с ним, поскольку это будет небезопасно и неприватно.
Что мы здесь видим, это список из Cipher suite в порядке убывания приоритета. Выделяю наиболее актуальный (ECDHE-ECDSA-AES256-GCM-SHA384), а вот наименее оптимальный, но все же сильный (ECDHE-RAS-AES128-SHA256). Плюс здесь указаны все наилучшие варианты, такие как версия TLS, тип сертификата, подпись сертификата и так далее.
Если подняться выше, то увидим совместимость этих шифров. Это самые старые совместимые клиенты, которые смогут работать с этими шифрами. Так что это и вправду отличный список сильнейших шифров, таких, которые вам стоит использовать в приоритете.
Также, если спуститься вниз, то здесь есть список, предназначенный для повышенной совместимости. Если вы ищите список, который будет работать с большим количеством клиентов, то это хороший вариант.
Спустимся еще ниже... Вот здесь, указаны все шифры. Еще ниже, видим вообще наиболее совместимый список, который будет работать с реально старыми клиентами.
Если вам нужно сконфигурировать сервер, то ознакомьтесь с этим. Это реально крутой инструмент. Если мы выберем нужный вид сервера... Итак, здесь выбираем сервер. Допустим, это Apache. Может быть, вам нужна устаревшая версия, или промежуточная, или актуальная, и затем нам выдается конфигурация. Видим здесь, что все уже настроено для нас. Не хотим SSLv3, TLSv1 или TLSv1.1 Так что он будет работать с TLSv1.2, и вот все наборы шифров. Этот инструмент сделал все красиво. Так что, да, это действительно классно.
Другой сайт для поиска хорошего списка с шифронаборами - это weakdh.org Вот один набор. И другой сайт я бы порекомендовал от Стива Гибсона, вот его список в формате, подходящем для серверов Windows. Это также хороший список в порядке приоритетности с наборами шифров.
В следующих статьях я расскажу вам, как вы можете определить, что сервер представляет из себя в плане своих алгоритмов шифрования, хешей, цифровых подписей и так далее.
SSL - это более старый протокол шифрования, а TLS более новый, однако люди до сих пор называют их одним названием - SSL, что немного раздражает и вводит в заблуждение. Множество сайтов по-прежнему используют старый SSL из-за вопросов совместимости, даже при условии, что из-за этого возникают проблемы в безопасности.
Примером использования TLS является HTTPS в URL-адресе веб-сайта, как, например, здесь. Но TLS может быть использован с любым другим протоколом типа FTP или в виртуальных частных сетях. Он используется не только с HTTP и не только для работы с веб-сайтами. TLS очень важен для безопасности и приватности в Интернете, поскольку это наиболее часто используемый способ шифрования данных в Интернете. TLS обеспечивает приватность, потому что с его помощью шифруются данные, и обеспечивает целостность, потому что он использует имитовставки, то есть коды аутентификации сообщений (MAC), во время обмена данными между двумя приложениями.
You must be registered for see images attach
Например, когда ваш веб-браузер, приложение, обменивается данными с вашим интернет-банком, их приложением, коммуникация шифруется по принципу end-to-end от вашего приложения до их приложения при помощи TLS.
TLS поддерживает средства защиты конфиденциальности или приватности, аутентификации и целостности. Соединение приватно, потому что симметричный алгоритм, например AES, который мы обсуждали, используется для шифрования передаваемых данных. Ключи для этого симметричного шифрования генерируются уникальным образом для каждого соединения, и они основаны на секретном ключе, согласованном в начале сеанса.
Сервер и клиент согласовывают детали, какой алгоритм шифрования и криптографические ключи они будут использовать перед тем, как первый байт данных будет отправлен. Согласование совместно используемого секретного ключа не может быть считано злоумышленником, даже атакующим, находящимся посередине соединения. Соединение также надежно в том, что атакующий не может модифицировать коммуникацию во время согласования и при этом остаться незамеченным.
Идентификационные данные лиц, обменивающихся данными, могут быть аутентифицированы при помощи криптографии с открытым ключом, сертификатов и цифровых подписей. Подобная аутентификация может использоваться по усмотрению, но в целом она обязательна для как минимум одной стороны, обычно для сервера, то есть веб-сайтов, которые вы посещаете. И я расскажу вам больше на эту тему, когда мы доберемся до сертификатов.
Соединение надежно, потому что каждое передаваемое сообщение проходит проверку целостности сообщения при помощи кодов аутентификации сообщений (MAC) с целью предотвращения невыявленной потери или изменения данных в процессе их передачи.
TLS поддерживает множество различных способов по обмену ключами, шифрованию данных и аутентификации целостности сообщений, многие из тех алгоритмов и технологий, которые мы уже обсуждали. И все же, в конечном итоге, безопасная конфигурация TLS включает в себя множество настраиваемых параметров, и не все из них позволяют использовать средства защиты приватности, аутентификации и целостности.
Лучше всего использовать Диффи-Хеллмана с эфемерными ключами — RSA (с прямой секретностью), либо Диффи-Хеллмана на эллиптических кривых с эфемерными ключами — RSA (с прямой секретностью), или же Диффи-Хеллмана на эллиптических кривых с эфемерными ключами — алгоритм цифровых подписей на основе эллиптических кривых ECDSA (с прямой секретностью). В общем-то, проблема в том, что у вас и выбор-то не всегда есть. Сервер поддерживает определенные аутентификацию и методы согласования ключей, и если вы хотите обмениваться с ним данными, то вам придется использовать то, что он предлагает. Причина, по которой лучше использовать эти способы, в том, что они используют протокол Диффи-Хеллмана для обмена ключами, что позволяет обеспечить такое свойство приватности, как "прямая секретность", здесь это указано.
You must be registered for see images attach
Это свойство дает гарантию, что ваши сеансовые ключи не будут скомпрометированы, даже если закрытый ключ сервера скомпрометирован. Это достигается тем, что уникальный сеансовый ключ генерируется для каждой сессии, которую пользователь инициирует. Даже компрометация единичного сеансового ключа не повлияет ни на какие данные, за исключением того обмена в том определенном сеансе, который защищался конкретно этим ключом.
Совершенная прямая секретность - это прогресс в вопросах по защите данных на транспортном уровне. Ее значимость увеличилась с момента появления таких уязвимостей, как Heartbleed. Итак, совершенная прямая секретность на деле означает, что если сервер, с которым вы общаетесь, скомпрометирован, и их закрытый ключ скомпрометирован, то все ваши предыдущие сеансы общения не могут быть дешифрованы, поскольку вы использовали протокол Диффи-Хеллмана для согласования сеансовых ключей, а они используются лишь в течение короткого промежутка времени.
Если мы спустимся ниже, то увидим используемые симметричные алгоритмы. Когда мы говорим о сеансовых ключах, то мы имеем ввиду ключи, которые используются непосредственно для шифрования данных, потому что симметричные ключи быстрее. И помните, мы говорили об AES, что выбор AES - это хороший вариант? В этой таблице мы видим его и различные другие виды алгоритмов симметричного шифрования.
Нам показано, какие из них защищенные, а какие нет, по причине различного рода уязвимостей или слабых мест, и вот почему я рекомендовал вам использовать AES. 10
Здесь вы можете заметить, что есть какие-то другие аббревиатуры в комбинации с AES. Вам не нужно особо волноваться на этот счет. Это называется "режимом использования". Это различные способы для AES по скремблированию или шифрованию данных, которые не имеют особого значения в нашем случае для предмета нашего обсуждения. Достаточно знать, что вы используете AES и длину в битах, мы уже разобрались в этом вопросе.
You must be registered for see images attach
Здесь вы также можете увидеть различные версии SSL. Собственно говоря, и это приводит многих людей в замешательство, первая версия SSL - это 2.0, самая ранняя версия из всех представленных в этой таблице, следующая версия - это SSL 3.0, далее идет TLS 1.0 Обратите внимание, следом за тройкой для SSL идет единица для TLS. Итак, TLS 1.3 - это самая последняя и наиболее защищенная версия, но она наименее совместима с браузерами. Когда вы используете TLS, вам реально стоит использовать TLS 1.0 или выше. Видим здесь, какие из них защищенные, а какие нет. Обратите внимание, что если вы используете TLS 1.0, то даже несмотря на AES, тут указано "Зависит от воздействия".
Давайте спустимся еще ниже. Здесь мы видим хеши, а также имито-вставки (MAC), которые используются с целью сохранения целостности данных. MD5 не стоит использовать, SHA1 определенно уже устарел, и нам стоит начать использовать актуальные версии SHA, а именно 256 и 384. Однако по причинам совместимости, они могут быть использованы не во всех случаях.
You must be registered for see images attach
Можете погуглить на этот счет и поискать детали, если интересно, а результатом всего этого стало то, что разработчикам пришлось обновлять браузеры и серверные реализации SSL, чтобы справиться с атаками и защититься от этих уязвимостей. Перейдем к следующей таблице, здесь мы видим список версий Firefox. В этой строке Firefox версий с 27-й по 33-ю. И вы можете увидеть уязвимости Beast, Crime, Poodle, Freak, Logjam. А если мы посмотрим на версии от 36-й до 38-й, то они подвержены уязвимости Logjam. Если будем смотреть на все более старые версии, то увидим, что они становятся все более и более подверженными различным слабостям и уязвимостям, вот почему вам следует использовать самую последнюю версию браузера, где это возможно. Серверы и сайты, на которые вы заходите, также должны быть обновлены до последних версий.
И все дело в том, что вы не можете всегда контролировать это. И если вам нужна приватность, максимальная приватность, и вы знаете, что ваш сервер не защищен, либо уязвим перед некоторыми из этих вещей, поскольку он, возможно, использует TLS 1.0, то вы должны понимать, что нельзя взаимодействовать с ним, поскольку это будет небезопасно и неприватно.
You must be registered for see images attach
Что мы здесь видим, это список из Cipher suite в порядке убывания приоритета. Выделяю наиболее актуальный (ECDHE-ECDSA-AES256-GCM-SHA384), а вот наименее оптимальный, но все же сильный (ECDHE-RAS-AES128-SHA256). Плюс здесь указаны все наилучшие варианты, такие как версия TLS, тип сертификата, подпись сертификата и так далее.
Если подняться выше, то увидим совместимость этих шифров. Это самые старые совместимые клиенты, которые смогут работать с этими шифрами. Так что это и вправду отличный список сильнейших шифров, таких, которые вам стоит использовать в приоритете.
Также, если спуститься вниз, то здесь есть список, предназначенный для повышенной совместимости. Если вы ищите список, который будет работать с большим количеством клиентов, то это хороший вариант.
You must be registered for see images attach
Спустимся еще ниже... Вот здесь, указаны все шифры. Еще ниже, видим вообще наиболее совместимый список, который будет работать с реально старыми клиентами.
You must be registered for see links
Если вам нужно сконфигурировать сервер, то ознакомьтесь с этим. Это реально крутой инструмент. Если мы выберем нужный вид сервера... Итак, здесь выбираем сервер. Допустим, это Apache. Может быть, вам нужна устаревшая версия, или промежуточная, или актуальная, и затем нам выдается конфигурация. Видим здесь, что все уже настроено для нас. Не хотим SSLv3, TLSv1 или TLSv1.1 Так что он будет работать с TLSv1.2, и вот все наборы шифров. Этот инструмент сделал все красиво. Так что, да, это действительно классно.
You must be registered for see links
You must be registered for see links
Другой сайт для поиска хорошего списка с шифронаборами - это weakdh.org Вот один набор. И другой сайт я бы порекомендовал от Стива Гибсона, вот его список в формате, подходящем для серверов Windows. Это также хороший список в порядке приоритетности с наборами шифров.
В следующих статьях я расскажу вам, как вы можете определить, что сервер представляет из себя в плане своих алгоритмов шифрования, хешей, цифровых подписей и так далее.