Краткое содержание:

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

Ключевые моменты:

1. SSL использует аутентификацию на основе сертификатов, в то время как SSH полагается на процесс аутентификации имени пользователя/пароля.
2. Шифрование – это процесс кодирования информации, чтобы она защищена от несанкционированного доступа.
3. Шифрование симметричного ключа использует один и тот же ключ как для шифрования, так и для дешифрования.
4. Асимметричное шифрование ключей, также известное как шифрование открытого ключа, использует ключевую паре, состоящую из закрытого ключа и открытого ключа.
5. Шифрование открытого ключа обеспечивает безопасное обмен клавишами и безопасные сообщения между сторонами.
6. Симметричное шифрование быстрее, чем шифрование открытого ключа, поэтому оно часто используется для шифрования объема данных.
7. Цифровые подписи используют шифрование открытого ключа для проверки подлинности и целостности сообщения.
8. Сертификатные власти обеспечивают ассоциацию общественных ключей со своими законными владельцами.
9. Алгоритмы криптографических хэш используются для проверки целостности данных в безопасных протоколах.
10. SSL/TLS и SSH широко используются безопасные сетевые протоколы для защиты данных во время передачи.

Вопросы:

1. Чем SSL отличается от SSH с точки зрения аутентификации?

SSL использует аутентификацию на основе сертификатов, в то время как SSH полагается на процесс аутентификации имени пользователя/пароля.

2. Что такое шифрование и какова его цель?

Шифрование – это процесс кодирования информации, чтобы она защищена от несанкционированного доступа. Его цель – обеспечить конфиденциальность и целостность данных.

3. Что такое симметричное шифрование ключей?

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

4. Как работает шифрование открытого ключа?

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

5. Каково преимущество шифрования открытого ключа?

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

6. Почему симметричное шифрование используется для шифрования объема данных?

Симметричное шифрование быстрее, чем шифрование открытого ключа, что делает его более эффективным для шифрования больших объемов данных.

7. Какие цифровые подписи?

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

8. Какова роль властей сертификата?

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

9. Какие криптографические алгоритмы используются для?

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

10. Для чего используются SSL/TLS и SSH?

SSL/TLS и SSH широко используются безопасные сетевые протоколы для защиты данных во время передачи. SSL/TLS обычно используется для безопасной веб -связи, а SSH используется для безопасного удаленного доступа и передачи файлов.

SSL против SSH-не очень технологическое сравнение

4. SSH использует процесс аутентификации имени пользователя/пароля для установления безопасного соединения, в то время как SSL не учитывает его.

Как работа SSL, TLS, SSH

В этой статье рассматривается, как работают безопасные сетевые протоколы. Это объяснит ключевые концепции, такие как шифрование, криптографический хэши и шифрование открытого ключа. Будут описаны два наиболее популярных протокола Secure Network, SSL/TLS и SSH, и их безопасные аналоги с передачей файлов, FTPS и SFTP будут описаны и сравниваются.

Что такое шифрование?

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

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

Существуют два основных типа шифрования – симметричное шифрование ключей и асимметричное, или шифрование открытого ключа.

Симметричное шифрование ключей

В симметричном шифровании ключ, используемый для шифрования простого текста, и ключа, используемый для расшифровки зашифрованного текста, одинаков. Это означает, что две стороны (отправитель и приемник) должны делиться ключом (который сам должен храниться в секрете). Конечно, определение того, как надежно поделиться ключом, является еще одним примером того, что предназначено для шифрования, для безопасного обмена информацией. Так как же две стороны разделяют свой секретный ключ? К счастью, это может быть достигнуто путем асимметричного (или открытого) шифрования, объяснено ниже. Популярные алгоритмы симметричного ключа включают AES, Blowfish, RC4 и 3DES.

Общедоступный ключ шифрование

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

Преимущество системы шифрования открытого ключа заключается в следующем: секрет (i.эн. Зашифрованные) сообщения могут быть отправлены всем, кто опубликовал свой открытый ключ, и только получатель сможет расшифровать сообщение. Поэтому до тех пор, пока их открытый ключ можно доверять, чтобы быть их (важное предостережение!), безопасная система для обмена секретными сообщениями может быть легко настроена. Каждая сторона может опубликовать свой открытый ключ и отправить секретные сообщения другому, используя другую’S public Key. Они используют свой собственный личный ключ для расшифровки сообщений, которые они получают.

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

RSA и Diffie -Hellman были самыми ранними алгоритмами открытых ключей. Долгое время считалось, что они были изобретены в 1976/1977 году, но когда в 1997 году было рассекречено исследование GCHQ, оказалось, что они были независимо задуманы несколько лет назад. Elgamal и DSS являются другими известными алгоритмами открытых ключей.
Существует ряд важных видов использования шифрования открытого ключа, описанного ниже.

Ключевое распределение

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

Шифрование открытого ключа идеально подходит для решения этой проблемы. Принимающая сторона, которой требуется отправитель’S Secret Symmetric Key, генерирует ключевую пасту и публикует открытый ключ. Отправитель использует приемник’S Public Key, чтобы зашифровать их симметричный ключ, и отправляет его в приемник. Теперь, и отправитель, и приемник имеют одинаковый секретный симметричный ключ, и никто другой не делает, поскольку он никогда не передавался в виде четкого текста. Это часто называют обменом ключа.

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

Цифровые подписи

Шифрование открытого ключа является важным компонентом цифровых подписей. Сообщение может быть подписано (зашифровано) с помощью пользователя’S закрытый ключ, и любой может использовать свой открытый ключ, чтобы убедиться, что пользователь подписал сообщение, и что сообщение не подделано. Это применение шифрования открытого ключа объясняется более подробно в следующем разделе, криптографический хэши.

Сертификат власти

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

Криптографический хэши

Алгоритмы криптографических хеш -хэш являются важными математическими функциями, широко используемыми в программном обеспечении, особенно в безопасных протоколах, таких как SSL/TLS и SSH.

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

Важной особенностью алгоритмов хэша является то, что, учитывая конкретный дайджест, чрезвычайно сложно сгенерировать сообщение, которое его создаст. Они есть “Одностороннее движение” Алгоритмы – дайджест сообщения легко рассчитать, но сообщение может’это будет выведен из дайджеста. Математически возможно, чтобы два разных сообщения давали один и тот же дайджест – известный как столкновение – но для хороших алгоритмов хэша это крайне маловероятно.

Популярные алгоритмы хеш-алгоритмы включают MD5 и SHA-1, хотя в настоящее время они выпускаются в пользу более сильных алгоритмов, таких как SHA-2.

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

Цифровые подписи

Письменная подпись демонстрирует, что документ был создан известным автором и точно представляет их. Цифровая подпись аналогична – она ​​гарантирует, что сообщение было создано известным отправителем (аутентификация) и что сообщение не было подделано в Transit (целостность).

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

Для проверки подписи сообщения также требуется два этапа. Во -первых, подписав’S Public Key (который широко доступен) используется для расшифровки цифровой подписи, давая дайджест сообщения. Затем рассчитывается усваивание сообщения сообщения и сравнивается с расшифрованным дайджестом. Если сообщение не было подделано, дайджесты должны быть идентичными. И потому что подписчик’S Public Key использовался для расшифровки подписи, подписавшего’S частный ключ должен был быть использован для его шифрования.

Зачем использовать сообщение’S Digest вообще? Почему бы просто не зашифровать сообщение с подписавшим’S закрытый ключ и используйте зашифрованное сообщение в качестве подписи? Хотя это, безусловно, сработало бы, это нецелесообразно – это удвоит размер сообщения, когда подпись включена. Дайджест очень маленький и фиксированного размера, поэтому шифрование дайджеста производит подпись, которая намного меньше.

Коды аутентификации сообщений (MAC)

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

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

Отправитель и получатель оба делятся секретным ключом. Когда получатель получает сообщение, они рассчитывают HMAC и сравнивают его с HMAC, предоставленным с сообщением. Если HMAC соответствуют, только кто -то, обладающий секретным ключом, мог бы произвести сообщение. Секретный ключ сам никогда не передается.

Пароли, пароль хэши и соли

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

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

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

Какие сертификаты?

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

Сертификатные власти являются решением этой проблемы. Управление сертификата ( “Калифорнийский”) – это организация, которая выпускает цифровые сертификаты. Цифровой сертификат – это электронный документ, который подтверждает право собственности на открытый ключ.

Цифровой сертификат содержит ряд полей – открытый ключ, который он сертифицирует владение, название владельца (субъект), имя эмитента (i.эн. CA), даты начала и окончания и эмитент’S Цифровая подпись. Цифровая подпись проверяет, что CA фактически выпустила сертификат. Цифровые подписи объясняются более подробно здесь.

Чтобы система работала, орган сертификации должен быть доверенным третьим стороной. Есть лишь небольшое количество CAS, включая Comodo, Symantec и Godaddy. CAS выпускают свои собственные сертификаты, содержащие их общедоступные ключи, которые известны как доверенные корневые сертификаты.

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

Валидация веб -сайта

Наиболее распространенным использованием сертификатов является проверка веб -сайтов HTTPS (i.эн. Веб -сайты, которые имеют URL -адрес https: //). Когда веб -браузер подключается к сайту, такому как Amazon, пользователь должен знать, что сайту можно доверять, я.эн. что URL www.Амазонка.COM фактически относится к сайту, контролируемому компанией Amazon. Это делается путем внедрения доменного имени веб -сайта в сертификат’S Объект субъекта при подаче заявки на CA для сертификата. CA гарантирует, что доменное имя контролируется организацией до выдачи сертификата. Веб -браузер имеет свой собственный список корневых сертификатов, и когда он подключается к сайту, сайт’S Сертификат отправляется веб -сервером. Используя сертификат CA, он проверяет, что сертификат, отправленный веб -сервером.

Почему эта проверка важна? Пока Amazon владеет своим доменным именем (что, как мы знаем,), почему нам нужен браузер, чтобы проверить сертификат?

К сожалению, вредоносное программное обеспечение может выдать себя за другую машину. Когда URL-адрес введен в веб-браузер, такой как https: // www.Амазонка.com, он должен быть переведен на IP -адрес, e.г. 192.168.1.64. Эти цифры-это то, что браузер использует для подключения к веб-серверу. Процесс перевода называется поиском DNS, и он включает в себя проверку общественного реестра доменных имен, чтобы получить IP -адрес, Amazon решил использовать. Злодие программное обеспечение может поставить под угрозу поиск DNS, возвращая неправильный IP -адрес, который может быть для поддельного веб -сайта, который похож на Amazon и предназначен для получения информации о кредитной карте.

Вот где проверка сертификатов доказывает, что его ценность – фальшивый веб -сайт может’T возвращает подлинный сертификат, и веб-браузер сообщает, что возвращенный сертификат не зарегистрирован для доменного имени, используемого в URL. В большинстве браузеров подлинный сайт будет отображать символ замок, и нажав на него мышью, покажет сайт’S Проверенная идентичность, как и в случае с Chrome, ниже.

Вот почему важно использовать URL -адреса, которые начинаются с HTTPS, а не HTTP – через сертификат браузер может предоставить гарантию, к которому сайт подключен является проверенным владельцем домена.

Как работает SSL/TLS?

История

Уровень Secure Sockets (SSL) – это криптографический протокол, предназначенный для обеспечения связи с сети TCP/IP. SSL был разработан NetScape в начале 1990 года’S, но различные недостатки безопасности означали, что это не было’T до SSL 3.0 был выпущен в 1996 году, что SSL стал популярным.

Именно в это время Эрик Янг была предоставлена ​​реализация SSL с открытым исходным кодом SSL, которая помогла обеспечить его широкое распространение в Интернете. Веб-сервер Apache также получил популярность, и Бен Лори из Apache Fame использовал Ssleay для создания Apache-SSL, одного из первых свободно доступных безопасных веб-серверов.

SSL стал безопасностью транспортного уровня (TLS) с публикацией TLS 1.0 Стандарт в 1999 году, за которым следует TLS 1.1 и TLS 1.2, самая последняя версия. Все версии TLS широко распространены, и только недавно поддержка SSL 3.0 был прекращен в ответ на уязвимость пуделя. Для простоты мы’l С. Ссылка на SSL/TLS как TLS для оставшейся части этой статьи.

Обзор

TLS предназначен для обеспечения безопасных соединений между клиентом (e.г. веб -браузер) и сервер (e.г. веб -сервер), шифруя все данные, передаваемые между ними.

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

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

Руководство SSL

А “рукопожатие” является наиболее важной частью SSL/TLS, так как именно здесь установлены важные параметры для соединения. Различные шаги в рукопожатии описаны ниже.
Безопасные сетевые протоколы 12

Шаг 1 – клиент привет

После установления подключения TCP/IP, клиент отправляет на сервер клиентский. В этом говорится максимальная версия TLS, которую клиент хочет поддержать, случайное число, список комплексных наборов, поддерживаемых в порядке предпочтения, и алгоритмы сжатия. Компания шифров является идентификаторами для группы криптографических алгоритмов, которые используются вместе. Например, TLS_RSA_WITH_AES_128_CBC_SHA означает, что сервер’S RSA Public Key должен использоваться, а алгоритм шифрования – 128 -битный AES. Алгоритм аутентификации сообщений (MAC) является HMAC/SHA-1.

ClientHello отправляется в ClareText, поэтому любой может перехватывать сетевые пакеты, может прочитать его.

Шаг 2 – сервер привет

Сервер отвечает на ClientHello с сообщением ServerHello. Он сообщает клиенту версию TLS для использования вместе с алгоритмом компрессии шифров и сжатием, которую он выбрал. ServerHello также предоставляет случайный номер, созданный сервером и идентификатор сеанса. ServerHello также отправляется в ClareText.

Сразу после отправки сервера Serverhello сервер отправляет свой сертификат, содержащий свой открытый ключ, клиенту. За этим следует дополнительное сообщение ServerKeyExchange, которое содержит любые дополнительные необходимые значения для обмена ключами.

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

Наконец, сервер отправляет клиенту сообщение ServerHelloDone, все еще в ClareText.

Шаг 3 – Проверьте сертификаты сервера

Как правило, у клиента есть кэш сертификатов или сертификаты CA ROY, с помощью которых он может убедиться, что сервер’S Сертификат является подлинным (и зарегистрировано на сервере’S IP -адрес). Если сервер’S Сертификат неизвестен, клиент может дать возможность принять сертификат в любом случае (что потенциально опасно) или может разорвать соединение. Это сообщение отправлено в ClareText.

Шаг 4 – Ответ клиента

Если сервер запросил сертификат у клиента, клиент отправляет свой сертификат, за которым следует сообщение ClientKeyExchange.

Для сообщения ClientKeyExchange клиент генерирует то, что называется Premaster Secret, состоящий из 48 байтов. Этот секрет отправляется на сервер как часть этого сообщения, но зашифруется с сервером’S Public Key (получен с сервера’S сертификат) так, чтобы только сервер мог расшифровать его с помощью закрытого ключа (поскольку сообщения все еще отправляются в виде простого текста).

Как только клиент и сервер поделились секретом Premaster, каждый из них использует его в сочетании с обоими случайными значениями, которые были обменены ранее для получения главного секрета, и впоследствии клавиши сеансов – симметричные ключи, используемые для шифрования и расшифровки данных в последующем сеансе TLS.

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

Шаг 5 – Проверьте сертификат клиента

Если сервер запросил сертификат клиента, подтверждается, чтобы убедиться, что он правильный.

Шаг 6 – Сервер завершен

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

Шаг 7 – Застройка установлена

К этому моменту все сообщения зашифрованы, и поэтому был установлен безопасный канал связи по всей сети между клиентом и сервером.

Записи и оповещения

Как упаковываются данные и отправляются через сеть после завершения рукопожатия? Это включает протокол записи и протокол оповещения.

Протокол записи

Протокол записи отвечает за сжатие, шифрование и проверку данных. Все данные для передачи разделены на записи. Каждая запись состоит из байта заголовка, за которым следует версия протокола, продолжительность отправки данных (известная как полезная нагрузка), и сама полезная нагрузка. Во -первых, данные сжаты, если сжатие было согласовано. Затем вычисляется Mac и добавляется к данным. Mac позволяет приемнику проверить, что запись не была подделана. Его расчет включает номер последовательности, который отправитель и приемник отслеживают. Наконец, данные и добавленные Mac зашифруются с помощью сеанса’S КЛЮЧЕСКИЕ КЛЮЧЕСКИЕ КЛЮЧЕСКИЕ ИСПОЛНИТЕЛЬНЫ. На приемном конце запись расшифрована, и Mac рассчитывается, чтобы убедиться, что запись’s данные не были подделаны. Если использовалось сжатие, оно распаковано.

Оповещения

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

Версии

Внутренние номера версий SSL/TLS не соответствуют, как можно ожидать, что публично называется номером версии. Например, 3.1 соответствует TLS 1.0. Основные версии, используемые в настоящее время, отображаются здесь.
Они полезны, чтобы быть знакомыми, так как внутренние номера версий часто предпочтительнее.

Уязвимости SSL/TLS

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

Некоторые из наиболее известных уязвимостей и то, как они были рассмотрены, обсуждаются ниже.

Сердце

Heartbleed – одна из самых серьезных уязвимостей, когда -либо обнаруженных в программном обеспечении TLS, позволяя краже серверных ключей, идентификаторов сеанса пользователей и паролей пользователей из скомпрометированных систем. Это был не недостаток протокола SSL, а скорее ошибка реализации (известная как переполнение буфера) в OpenSSL‘S Бесплатная библиотека, которая широко используется в Интернете. Миллионы машин были затронуты, и многочисленные успешные атаки сообщили.

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

По оценкам, общая стоимость Heartbleed находится в диапазоне сотен миллионов долларов.

ПУДЕЛЬ

Пудель – это уязвимость в более старом протоколе SSL, SSL 3.0. В то время как большинство систем используют TLS 1.0, 1.1 или 1.2, Протокол TLS имеет положение о плате, позволяющее взаимодействовать с более старым программным обеспечением, все еще используя SSL 3.0. Таким образом, атаки пуделя используют это положение о падении, чтобы дурачить серверы, чтобы понизить SSL 3.0.
Самое простое исправление – отключить SSL 3.0 в клиентах и ​​серверах. SSL 3.0 был опубликован в 1996 году, он уже давно заменен, и не должно быть необходимости поддерживать его после почти 20 лет. Пудель – гораздо менее серьезная уязвимость, чем сердце.

RC4

RC4 – широко используемый шифр TLS, который больше не считается безопасным. RC4 также известен как ARC4 или ARCFOUR (потому что RC4 является товарным знаком). Его скорость и простота сделали RC4 популярной, но недавно (февраль 2015 г.) RFC7465 рекомендовал его больше не использовать.

Протокол передачи файла SSL/TLS: FTPS

Одним из наиболее распространенных использований SSL/TLS является безопасная форма передачи файла, известная как FTPS.

Традиционный FTP, как определено в RFC 959, не упоминает о безопасности. Это понятно, как было написано в 1985 году и основано на спецификациях 1970 -х годов. Это было, когда университеты и военные были основными пользователями Интернета, и безопасность не была проблемой, которой она является сегодня.

В результате в FTP пользовательские названия и пароли (до сих пор) отправляются по сети в четком тексте, а это означает, что любой, кто может понюхать пакеты TCP/IP, может их захватить. Если FTP -сервер находится в Интернете, пакеты проходят через общедоступные сети и должны считаться общедоступными.

Только в 1990 -х годах, когда Netscape разработал свой Secure Sockets Layer (SSL), решение стало практичным. Проект RFC в 1996 году описал расширение на FTP, называемое FTPS, которое позволило использовать команды FTP через соединение SSL, и к 2005 году это было разработано в формальный RFC.

Реализовано такими клиентами, как Filezilla и серверы, такие как Proftpd, FTPS быстро стал популярным.

Неявные FTPS

Есть две формы FTPS – неявный режим и явный режим. Неявный режим FTPS устарел и не широко используется, но все еще иногда встречается.

Неявные FTPS не имеют явной команды для обеспечения сетевого соединения – вместо этого это неявно. В этом режиме FTPS Server ожидает, что клиент FTPS немедленно инициирует рукопожатие SSL/TLS при подключении. Если это не так, соединение отбрасывается. Стандартный порт сервера для подключений неявного режима составляет 990 (не стандартный порт 21, используемый для FTP).

После установки подключения SSL/TLS стандартные команды FTP используются для навигации по серверу’S -файловая система и передача файлов. Поскольку соединение безопасно, пароли могут быть отправлены, и данные не могут быть проверены подслуженными.

Явные FTPS

В явном режиме FTPS клиент должен явно запросить подключение, которое будет защищено, отправив команду Auth TLS на сервер. Как только эта команда отправлена, рукопожатие SSL/TLS начинается, как и с неявными TLS, и командное соединение защищено.

Преимущество использования явного режима FTPS в неявном режиме состоит в том, что может использоваться тот же номер порта, что и стандартный FTP – порт 21. Обычные пользователи FTP просто не отправляют команду Auth, и поэтому они никогда не защищают соединение. Администратор сервера может потребовать использования команды AUT.

Явные режимы FTP всегда должны использоваться в предпочтениях в неявном режиме, в первую очередь потому, что неявный режим устарел в течение многих лет.

Недостаток FTPS

FTPS имеет один значительный недостаток, который представляет собой использование отдельного сетевого соединения для данных, включая содержание файлов и списки каталогов. Это на самом деле является частью протокола FTP – команды отправляются через начальный “контроль” соединение на порту 21, и всякий раз, когда данные передаются, для передачи должно быть установлено новое сетевое соединение. Клиент и сервер должны договориться о номере порта, и необходимо открыть соединение.

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

Более важная проблема – это пережить брандмауэры. Брандмауэры обычно настроены, чтобы разрешить доступ через порт 21. Современные брандмауэры также достаточно умны, чтобы иметь возможность осмотреть команды, отправляемые между клиентом и сервером (порт или PASV), чтобы определить, какие порты должны быть динамически открыты, чтобы разрешить передачи данных.
Однако с FTPS команды находятся на зашифрованном канале, а брандмауэры не могут их осмотреть. Это означает, что они не могут автоматически открывать порты данных, и поэтому переносы и списки каталогов не сбои. Вместо этого должен быть согласован фиксированный диапазон портов и настроен на клиент, сервер и брандмауэр.

Будущее FTPS

В настоящее время FTPS имеет сильного конкурента в SFTP или SSH -протоколе передачи файлов. Они совершенно разные протоколы, и их относительные достоинства будут рассмотрены в следующем разделе. Тем не менее, FTP и FTP имеют огромную базу установки и, несомненно, будут продолжать широко использоваться в течение многих лет.

Как работает SSH?

SSH ИСТОРИЯ

В конце 1980 года’S и 1990’S, сетевые инструменты, такие как Rlogin и Telnet, обычно использовались для входа в удаленные машины, обычно на платформах UNIX. Эти инструменты позволили пользователям открывать командные оболочки, которые позволили им выполнять команды на удаленных машинах, как если бы они были на машине, и были чрезвычайно полезны для системного администрирования.

Был один критический недостаток – ни один из этих инструментов не был безопасным. Пароли были отправлены через сети в простом тексту, что означает, что любой, кто мог понюхать сеть, мог получить учетные данные для удаленной машины. Эта проблема заключается в том, почему Tatu Ylönen, финский исследователь из Технологического университета Хельсинки, решил, что требуется протокол безопасной сети. В 1995 году он написал первую версию SSH, известную как SSH-1, и выпустил ее в качестве бесплатного программного обеспечения. Он состоял из безопасного сервера и клиента.

Поскольку его популярность быстро росла, Илнен основал SSH Communications Security для рынка и разрабатывает SSH как запатентованный продукт. В 1999 году Björn Grönvall начал работать над более ранней бесплатной версией, и команда OpenBSD финансировала свою работу по созданию свободно доступных OpenSsh. Вскоре были сделаны порты для многих других платформ, и OpenSsh остается наиболее широко известной и использованной версией SSH.

В 2006 году SSH 2.0 было определено в RFC 4253. SSH-2 несовместим с SSH-1 и имеет улучшенную безопасность и функции, что делает SSH-1 устаревшим.

Обзор SSH

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

• безопасные инструменты удаленного входа, такие как клиент SSH;
• безопасная передача файлов, например, инструменты SCP и SFTP; и
• Безопасная пересылка порта или безопасное туннелирование.

SSH-2 использует многоуровневую архитектуру и состоит из транспортного уровня, уровня аутентификации пользователя и слоя соединения.
Транспортный уровень работает по TCP/IP и обеспечивает шифрование, аутентификацию сервера, защиту целостности данных и необязательное сжатие. Уровень аутентификации пользователя обрабатывает аутентификацию клиента, в то время как уровень подключения предоставляет такие услуги, как интерактивные логики, удаленные команды и перенаправленные сетевые подключения.

Транспортный слой

Транспортный уровень основан на сообщениях и обеспечивает шифрование, аутентификацию хоста и проверку целостности. Сообщения отправляются между клиентом и сервером через TCP/IP через протокол двоичного пакета – “пакеты” данных обмениваются в формате, определенном ниже, а полезная нагрузка каждого пакета – это сообщение:
uint32 packet_length byte padding_length byte [n1] полезная нагрузка; n1 = packet_length – padding_length – 1 байт [n2] случайная прокладка; n2 = padding_length byte [m] mac (код аутентификации сообщения – Mac); m = mac_length

Mac является важным полем, потому что именно Mac позволяет получателям сообщений быть уверенным, что сообщения не были подделаны – проверка целостности, упомянутая выше. Mac рассчитывается по сравнению с остальными данными в пакете и использует общий секрет, установленную между клиентом и сервером, и номер последовательности, который обе стороны отслеживают. Mac описаны в этом посте.

Создание сеанса

Как начинается сеанс между клиентом и сервером? Каждая сторона отправляет идентификационную строку после установки соединения TCP/IP. Эта строка находится в следующем формате:
SSH-2.0-softwareversion sp Комментарии Cr lf

Здесь “Шрифт” означает пространство, “Герметичный” это персонаж возврата кареты, и “LF” это линейный корм. Версия программного обеспечения является версией поставщика, а комментарии и пространство необязательны. Таким образом, в случае FoolftP, когда клиент подключается к серверу, он получает следующую строку:
SSH-2.0-completeftp_9.0.0

Строка заканчивается обязательной возвратом и подачей линии – никаких комментариев не используется.

После обмена строк идентификации необходимо согласовать ряд вариантов-шифры, используемые для шифрования, алгоритмы Mac, используемые для целостности данных, методы обмена ключами, используемые для настройки одноразовых клавиш сеанса для шифрования, алгоритмы общедоступного ключа, которые используются для аутентификации, и, наконец, какие алкогольные аллеры используются общедоступными ключами. Как клиент, так и сервер отправляют друг другу сообщение SSH_MSG_KEXINIT, в котором указаны свои предпочтения для этих параметров:
byte ssh_msg_kexinit byte [16] cookie (случайные байты)-l-list kex_algorithms name-list server_host_key_algorithms name-list MS_SERVER_TO_CLIENT Имя-списка Compression_Algorithms_client_to_server Имя списка сжатия

Это сообщение является полезной нагрузкой двоичного протокола пакета, формат которого описан выше. Списки имен алгоритмов разделены запятыми. Клиент отправляет списки алгоритма в порядке предпочтения, в то время как сервер отправляет список алгоритмов, которые он поддерживает. Первый поддерживаемый алгоритм в порядке клиента’S предпочтением является алгоритм, который выбран. Учитывая оба сообщения, каждая сторона может выяснить, какие алгоритмы должны использоваться.

После SSH_MSG_KEXINIT выбранное алгоритм обмена ключами, который может привести к обмену ряда сообщений. Конечный результат – два значения: общий секрет, k и обмен хэш, h. Они используются для получения клавиш шифрования и аутентификации. SSH_MSG_NEWKEYS отправляется для обозначения конца этих переговоров, и каждое последующее сообщение использует новые клавиши шифрования и алгоритмы.

С установленным соединением SSH-2 клиент запрашивает “услуга” (Обычно SSH-USERAUTH, чтобы начать процесс аутентификации) с сообщения SSH_MSG_SERVICE_REQUEST.

Уровень аутентификации

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

Аутентификация пользователя инициируется клиентом с “услуга” Запрос на услугу SSH-USERAUTH. Если сервер отвечает, разрешив запрос, клиент отправляет запрос на аутентификацию, который включает в себя их имя пользователя и метод аутентификации.

Существует ряд возможных методов аутентификации, и какой из них используется, будет зависеть от клиента и сервера’S Поддержка этого. Самым популярным методом является аутентификация пароля, которая является самоуверенной. Другой – аутентификация PublicKey. Как правило, клиент предлагает метод, и сервер либо принимает, либо отклоняет этот метод.

Пример запроса аутентификации пароля пользователем под названием “предприятие” показан ниже:
byte ssh_msg_userauth_request string “enterprisedt” [имя пользователя] строка “ssh-userauth” [имя службы] строка “пароль” [метод аутентификации] логическая строка “mypassword” [пароль пользователя]

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

Если запрос на аутентификацию пользователя отклонен (например, был предоставлен неправильный пароль), сервер отправляется сообщение об отказе, и оно предоставляет список альтернативных аутентификаций, которые можно попробовать.

Обычно отправлять “никто” В качестве первоначального метода аутентификации, и сервер обычно отвечает сообщением о сбое, содержащем список всех доступных методов аутентификации. Пример ответа на “никто” показан ниже:

Byte SSH_MSG_USERAUTH_FAILURE Имя пароль-списка, PublicKey Boolean False (частичный флаг успеха)

Здесь сервер информирует клиента, что можно использовать либо пароль, либо аутентификацию PublicKey.
Если запрос на аутентификацию пароля преуспевает, сервер возвращает сообщение о успехе, как показано ниже:
Byte SSH_MSG_USERAUTH_SUCCESS

На этом этапе аутентификация завершена, а другие услуги могут быть запрошены. Они могут включать запросы на пересылку TCP/IP, а также каналы для доступа к терминалу, выполнения процесса и подсистем, таких как SFTP.

Слой соединения

Последний кусок SSH-2’S Многоуровневая архитектура – это слой соединения, который предоставляет сетевые услуги, такие как интерактивные сеансы и перенаправление портов поверх транспортного уровня, который обеспечивает необходимую безопасность.

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

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

Сообщение SSH_MSG_CHANLER_OPEN, используемое для открытия интерактивного сеанса, показано ниже. Этот сеанс может быть впоследствии использован для сеанса терминала, для запуска удаленной команды или для запуска подсистемы, такой как SFTP.

byte ssh_msg_channel_open string “session” uint32 канал отправителя uint32

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

Получатель этого сообщения отвечает сообщением SSH_MSG_CHANLEN_OPEN_CONFIRMTION, если оно готово открыть запрошенный канал:
byte ssh_msg_channel_open_confirmation uint32

Как только канал был успешно открыт, данные могут быть обменены, а запросы на специфичные для специфики для канала могут отправляться. Когда размер скользящего окна для клиента или сервера становится слишком маленьким, владелец окна отправляет сообщение ssh_msg_channel_window_adjust, чтобы увеличить его:
byte ssh_msg_channel_window_adjust uint32 канал получателя uint32 bytes, чтобы добавить

Данные отправляются через канал через сообщение SSH_MSG_CHANLEN_DATA. Как используются данные, будет зависеть от типа установленного канала:
byte ssh_msg_channel_data uint32

Запросы канала используются для выполнения определенных действий по каналу. Общие запросы включают запуск оболочки или выполнение удаленной команды. Например, удаленная оболочка запускается по запросу, указанному ниже:

byte ssh_msg_channel_request uint32 строка канала получателя “Shell”

Удаленная команда выполняется следующим запросом:
Byte SSH_MSG_CHANLEN_REQUEST UINT32 Строка канала получателя “Exec”

Наконец, по этому запросу может быть открыта подсистема SFTP:
byte ssh_msg_channel_request uint32 строка канала получателя “Подсистема” Boolean Want string string “sftp-server”

Подсистемы представляют собой наборы удаленных команд, которые предварительно определен на серверной машине. Наиболее распространенным является SFTP, который предоставляет команды для передачи и манипулирования файлами. Команды подсистемы (включая протокол SFTP) работают над SSH, i.эн. Данные для команд подсистемы отправляются в сообщениях ssh_msg_channel_data.

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

Протокол передачи файлов SSH: SFTP

Наиболее распространенной подсистемой, используемой с SSH, является SFTP, которая предоставляет команды для передачи и манипулирования файлами. SFTP также известен как протокол передачи файлов SSH и является конкурентом FTPS – традиционный FTP через соединение SSL/TLS.

Подсистема SFTP работает над транспортным уровнем SSH, но сама по себе сложный протокол, основанный на сообщении. Сообщения SFTP передаются в качестве поля данных транспортного уровня’S SSH_MSG_CHANLEN_DATA Сообщение
Сообщения SFTP находятся в стандартном формате, как показано ниже:
uint32 длина байта типа Uint32-ID запроса . Тип конкретных полей ..

Первое поле – длина сообщения, исключая поле длины, а затем – тип сообщения. Третье поле – идентификатор запроса – каждый запрос, отправленный от клиента, имеет идентификатор запроса, а сервер’S ответ должен включать соответствующий идентификатор запроса.

Некоторые из наиболее важных сообщений SFTP вместе с их идентификаторами типа показаны и описаны ниже:
SSH_FXP_INIT 1 SSH_FXP_VERSION 2 SSH_FXP_OPEN 3 SSH_FXP_CLOSE 4 SSH_FXP_READ 5 SSH_FXP_WRITE 6 SSH_FXP_STATUS 101 SSH_FXP_DATA 103

SSH_FXP_INIT – это первое сообщение, отправленное клиентом для инициирования сеанса SFTP, и сервер отвечает SSH_FXP_Version, указывая на версии, которые он поддерживает.
SSH_FXP_OPEN запрашивает сервер открыть файл (или, необязательно создать его, если он не существует), пока

Ssh_fxp_close закрывает файл. SSH_FXP_REAR. SSH_FXP_WRITE используется для записи данных в файл, и одним из его полей является данные для записи (а также смещение в файл).

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

Существуют также команды для других стандартных операций файлов и каталогов, таких как удаление файлов (ssh_fxp_remove), переименование файлов (ssh_fxp_rename), а также создание и удаление каталогов (ssh_fxp_mkdir, ssh_fxp_rmdir). Директории читаются путем их открытия (SSH_FXP_OPENDIR) и отправляя запросы SSH_FXP_REEDDIR. Опять же, SSH_FXP_STATUS используется для указания успеха или неудачи этих запросов.

Не существует конкретного сообщения SFTP для прекращения сеанса SFTP – вместо этого клиент закрывает используемый канал SSH.

Важно отметить, что SFTP является совершенно другим протоколом для традиционного FTP, я.эн. это не команды FTP, отправленные через соединение SSH. Напротив, FTPS – это команды FTP, отправленные через соединение SSL/TLS. Два протокола легко запутаны, так как они оба являются безопасными протоколами для передачи файлов.

SFTP против FTPS

Мы описали, как работают FTPS и SFTP, выше. По сути, оба протокола достигают точно одинаково-безопасная передача файлов и безопасная, удаленная манипуляция с файловыми системами.

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

Существующее использование, естественно, является важным соображением. Если SFTP и/или SSH уже используются в других областях организации, разумно использовать SFTP. Существующие знания и навыки в организации могут быть использованы, а также техническая инфраструктура. Точно так же, если FTP и/или FTPS уже используются в другом месте, лучше всего использовать FTPS.

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

Но что, если отправной точкой является совершенно чистый лист, и нет никаких ограничений, на каких протоколах можно использовать? Есть ли явный победитель?

SFTP – явный победитель

Да, и это SFTP. Несколько лет назад такое решение было не таким простым, в основном из -за доминирования протокола FTP в большинстве организаций. Теперь клиенты и серверное программное обеспечение широко доступно как для SFTP, так и для FTPS – на самом деле многие приложения, такие как поддержка FulfftP Оба.

Это означает, что решение может быть принято по чисто техническим причинам, и SFTP имеет как минимум два важных технических преимущества по сравнению с FTP и FTPS.

SFTP лучше с брандмауэрами

FTPS может быть болезненным, чтобы работать с брандмауэрами. Это связано с тем, что списки каталогов и передачи файлов сделаны на новом сетевом соединении, которое разделено на канал управления на порту 21. По умолчанию брандмауэры не разрешат эти соединения в FTPS (хотя это обычно работает с FTP, поскольку брандмауэры могут осмотреть сетевой трафик и заранее открыть соответствующий порт). Вместо этого брандмауэр и сервер должны быть настроены для определенного диапазона портов для передачи данных, что может быть сложным.

Напротив, SFTP просто работает с брандмауэрами. Данные и команды отправляются по стандартному порту 22, который обычно включается с брандмауэрами по умолчанию. Это значительное преимущество перед FTP.

SFTP делает’T Используйте сертификаты

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

SFTP делает’T Используйте сертификаты – сервер идентифицируется по его открытому ключу (что содержит сертификат, поэтому они оба в конечном итоге используют один и тот же механизм). Таким образом, если у клиента есть общедоступный ключ сервера, он может подтвердить, что сервер является правильным. Сервер’S Public Key (в отличие от сертификата) может быть сгенерирован организацией, а орган сертификации не требуется. Это значительно уменьшает объем администрирования, необходимую для запуска сервера.

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

Есть ли недостаток в использовании SFTP?

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

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

Заключение

Этот контент объяснил, как работают SSL/TLS и SSH для обеспечения передачи данных по сети, и, в частности, FTPS и протоколы SFTP. Несмотря на то, что FTPS и SFTP аналогичны аналогично. В первом сравнении SFTP выходит на первое место, хотя может быть целесообразно выбирать обоих протоколов в технической инфраструктуре вашей организации.

Другие технические статьи

• Что является управляемой передачей файла (MFT)?
• Что такое SFTP?
• Что такое FTP?
• Что такое FTPS?
• FTPS против SFTP

SSL против SSH-не очень технологическое сравнение

Знаете ли вы, что SFTP и FTP получают свою безопасность из базовых протоколов? Откройте для себя сходства и различия между SSH и SSL сегодня!

Обзор

Наиболее широко используемые протоколы передачи безопасных файлов, SFTP и FTPS, получите свою безопасность из базовых протоколов. SFTP от SSH и FTP от SSL. Давайте сравним два.

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

FTP-это протокол на основе TCP. Следовательно, это может быть очень полезно для загрузки/загрузки файлов по локальной сети или даже через Интернет. Тем не менее, FTP был разработан в то время, когда использование Интернета было ограничено несколькими организациями и сетевыми угрозами не существовало.

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

FTPS фактически получает свою защиту от SSL/TLS (безопасные гнезда слоя/транспортного уровня безопасности), в то время как SFTP получает свои собственные от SSH (Secure Shell).

Сходство между SSH и SSL

Когда вы сравниваете их атрибуты безопасности, вы обнаружите, что SSH и SSL имеют очень сильное сходство. Они оба предлагают шифрование данных, аутентификацию сервера, аутентификацию клиента и механизмы целостности данных.

Шифрование данных в движении

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

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

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

Незашифрованное соединение (e.г. FTP)

Зашифрованное соединение (e.г. SFTP или FTPS)

Как SSH, так и SSL предоставляют шифрование данных в движении через так называемое шифрование симметричного ключа. Этот вид шифрования использует общий ключ, который используется как для шифрования, так и для дешифрования. Некоторые общие симметричные цифры включают AES, 3DES, Blowfish, Twofish и RC4.

Аутентификация сервера и клиента

Зашифрованное соединение становится бесполезным, если вы неосознанно подключены к фиктивному серверу или злонамеренному клиенту. В то время как SSH и SSL используют симметричную криптографию для сохранения конфиденциальности передаваемых данных, они используют другую форму шифрования для аутентификации. Аутентификация позволяет одной стороне проверить, действительно ли другая сторона, которой она утверждает.

Для реализации аутентификации SSH и SSL используют асимметричную криптографию A.k.а. Криптография открытого ключа. Популярными алгоритмами шифрования открытых ключей являются RSA, DSA и ECDSA, которые поддерживаются как SSH, так и SSL.

В отличие от симметричного шифрования, в котором используется один ключ для шифрования и дешифрования, асимметричное шифрование использует два ключа – открытый ключ и закрытый ключ.

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

И наоборот, шифрование открытого ключа также может использоваться сервером для аутентификации клиента. Это известно как аутентификация клиента. Статья Что такое ключ SFTP Включает хорошее введение по аутентификации клиентов и криптографии открытого ключа.

Механизмы целостности данных

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

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

Механизмы целостности данных позволяют осуществляющим сторонам проверять, было ли переданное сообщение неизменным на этом пути. Алгоритмы Mac (код аутентификации сообщений), такие как SHA1, SHA256 (и другие версии SHA) и MD5, как правило, используются SSH и SSL для проведения проверки целостности данных в передаваемых сообщениях.

Хешинг понимания статьи включает в себя приятное обсуждение по этому вопросу.

Различия между SSL и SSH

Одним из наиболее заметных различий между SSL/TLS и SSH является то, что SSL обычно (да, может быть исключения) использует x.509 цифровых сертификатов для аутентификации сервера и клиента, тогда как SSH не. А поскольку SSL использует цифровые сертификаты, он, следовательно, также требует наличия инфраструктуры открытого ключа (PKI) и участия Управления сертификации (CA).

Хотя можно использовать так называемые сертификаты, известные как саморегистрированные сертификаты, и в этом случае SSL становится очень похожим на SSH из-за отсутствия CA, это не рекомендуемая практика. Самоподобные сертификаты приемлемы только в внутриорганизационных транзакциях, за исключением крупных (E.г. Глобально распределенные) организации.

Еще одно большое отличие состоит в том, что в SSH в него встроена больше функциональности. Например, самостоятельно, SSH может позволить пользователям входить в систему на сервер и удаленно выполнять команды. SSL не имеет этой возможности. Вам нужно будет соединить его с другим протоколом (E.г. Http, ftp или webdav), чтобы иметь аналогичные функции.

SSH также легко поддерживает мультиплексирование соединения, управление потоком, управление терминалами и другие функции. Конечно, эти дополнительные функции больше не подпадают под наше первоначальное обсуждение, в котором мы начали сравнивать SSL и SSH по отношению к SFTP и FTPS.

Итак, прежде чем мы уйдем дальше, давайте закончим здесь.

Начать

Хотите попробовать сервер передачи файлов, который поддерживает FTPS и SFTP, а также другие протоколы? Попробуйте бесплатное, полностью функциональное издание оценки JSCAPE MFT Server сегодня.

Популярные статьи

Настройка аутентификации открытого ключа SFTP в командной строке

6 мин ЧИТАЕТ – 11 декабря 2022 г

SFTP позволяет вам аутентифицировать клиентов, используя общественные ключи, что означает, что они выиграли’T нужен пароль. Узнайте, как настроить это в командной строке онлайн. Прочтите статью

Активный против. Пассивный FTP упрощен: понимание портов FTP

7 минут прочтения – 11 декабря 2022 года

Если есть проблемы с подключением к вашему FTP -серверу, проверьте режим передачи. Позвольте JScape помочь вам понять разницу в активном и пассивном FTP. Прочтите статью

Активно-активный против. Активно-пассивная кластеризация высокой доступности

3 мин Читает – 11 декабря 2022 г

Наиболее часто используемые конфигурации кластеризации с высокой доступностью активны и активны. Узнайте разницу между двумя онлайн! Прочтите статью

Использование скриптов Windows FTP для автоматизации передачи файлов

4 мин Читает – 11 декабря 2022 г

Узнайте, как автоматизировать передачи файлов, используя скрипты Windows FTP. В этом посте объясняется, что такое сценарии FTP и как создавать простые сценарии для передачи файлов. Прочтите статью

Использует ли SSH TLS или SSL

Охто

Мы аррегировали подоаджолгн. SpoMOщHщ эtOй straoniцы mы smosememememopredetath, чto -aprosы otpra. То, что нужно?

Эta -steraniцa otobrana -overshy -aTeх -stuчah -obra -aTeх -stu -y -y -ogdaTomAtiчeskymi -stri -stri -rah -strhe -strhe -strhe -stri -stri -stri -stri -stri -stri -rah -rah -stristriouri Котора. Straoniцa -oprepaneTeTeTeTeTOTOTOTO -opobrasthep -apoSle -o, kak -эat. ДО СОМОМОНТА.

Иошнико -а -а -а -в -впологовый схлк -а -апросов. Esli-yspolheoute obhщiй dostup-vanterneTTHETHETHETHETHET,. Охраторс. Подеб.

Проверка, в котором я, eSli -voAchephephephephe -yvodyte -sloжne -apro Эмами, Или,.

SSH против SSL: различия и сходства между ними [Minitool Tips]

Каковы различия между SSH и SSL? Какая из них лучше? Если вы пытаетесь найти эти вопросы’ Ответы, этот пост – то, что вам нужно. Этот пост из Minitool предоставляет их определения, а также информацию о SSH против SSL.

Что такое SSH

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

SSH можно использовать только на компьютерах на основе UNIX изначально, но теперь вы можете использовать его в Windows. SSH – это протокол шифрования, который создает туннель между двумя удаленными компьютерами. Может быть, этот пост – как настроить клиент и сервер SSH в Windows 10 [Полное руководство] – это то, что вам нужно.

Что такое SSL/TLS

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

SSH VS SSL

SSH и SSL/TLS обычно имеют разные использование. SSH используется для выполнения задач, с которыми обычным интернет -пользователям никогда не приходится иметь дело. С другой стороны, обычные интернет -пользователи используют SSL/TLS. Ниже приведена информация о SSL VS SSH.

Сходства

Теперь, пусть’S видит сходство между SSH и SSL. Во-первых, как SSH, так и SSL являются трехзначными аббревиатурами, которые начинаются с одной и той же буквы. Далее, это два протокола, используемые в безопасных соединениях. Наконец, оба они используют шифрование для защиты данных, передаваемых между двумя сетевыми устройствами.

Различия

Только сейчас вы знали сходство между SSH и SSL. Тогда пусть’S Смотрите различия между SSH и SSL.

1. SSH работает на порту 22, а SSL работает на порту 443.

2. SSH основан на сетевых туннелях, а SSL основан на сертификатах.

3. Технически, SSH используется для защиты компьютерной сети, в то время как SSL используется для защиты онлайн -передачи данных.

4. SSH использует процесс аутентификации имени пользователя/пароля для установления безопасного соединения, в то время как SSL не учитывает его.

5. SSL используется для безопасной передачи ключевой информации, такой как кредитные карты и банки. И SSH используется для безопасного выполнения команд в Интернете.

6. SSL обычно (за исключением исключений) использует x.509 цифровых сертификатов для аутентификации сервера и клиента, в то время как SSH не.

7. SSL используется для шифрования связи между браузером и сервером. С другой стороны, SSH используется для шифрования связи между двумя компьютерами в Интернете.

8. В SSL коммуникация аутентифицирована частной/открытой парой ключей. В SSH связь аутентифицируется через пары частных/открытых ключей или пары имени пользователя/пароля.

9. Другое важное отличие состоит в том, что SSH имеет больше встроенных функций, чем SSL. Он помогает вам войти на сервер и выполнять команды удаленно, и SSL не имеет этой функции. Для достижения этой функции вам нужно сочетать ее с другими протоколами – HTTP, FTP.

5 способов решить http error 401 несанкционированный

При открытии браузера для поиска что -то, вы можете наткнуться на ошибку HTTP 401. Этот пост показывает, как решить эту ошибку 401.

Последние слова

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

• Facebook
• Twitter
• LinkedIn
• Reddit

Об авторе

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