Sha1sum mismatch

несоответствие хэш-суммы пакетов debian apt

Sha1sum mismatch

из командной строки Debian я получаю несоответствие хэш-суммы после выполнения aptitude update; aptitude upgrade. Ниже приведен вывод командной строки. Я пробовал aptitude clean, но это похоже не помогло. Я также сделал несколько поисков в google, но ничего не помогает. Я получаю ошибку несоответствия в течение нескольких дней.

любая помощь приветствуется.

Resolving dependencies…open: 405; closed: 880; defer: 58; conflict: 78.The following packages will be upgraded: apache2.2-bin apt-utils aptdaemon aptdaemon-data avahi-daemon bind9-host dnsutils ekiga gir1.2-cogl-1.0 gir1.2-coglpango-1.0 gstreamer0.10-alsa gstreamer0.10-ffmpeg gstreamer0.10-plugins-base gstreamer0.10-x host libapt-inst1.5 libavahi-client3 libavahi-common-data libavahi-common3 libavahi-core7 libavahi-glib1 libavahi-gobject0 libavahi-ui-gtk3-0 libavahi-ui0 libavutil51 libbind9-80 libcapi20-3 libcogl-common libcogl9 libdbus-glib-1-2 libdns88 libgconf2.0-cil libgssapi-krb5-2 libgssrpc4 libgstreamer-plugins-base0.10-0 libisc84 libisccc80 libisccfg82 libk5crypto3 libkrb5-3 libkrb5support0 liblwres80 libmp3lame0 libmtp-common libmtp-runtime libmtp9 libpostproc52 libruby1.8 libswscale2 libsystemd-login0 libtag1-vanilla libtag1c2a libxml2 libxml2-utils linux-headers-3.2.0-4-686-pae linux-headers-3.2.0-4-common linux-image-3.2.0-4-686-pae linux-libc-dev linux-source-3.2 python-aptdaemon python-aptdaemon-gtk python-aptdaemon.gtk3widgets python-aptdaemon.gtkwidgets python-libxml2 python-numpy ruby1.8 telepathy-gabble unattended-upgrades xserver-xorg-video-ati xserver-xorg-video-radeonThe following packages are RECOMMENDED but will NOT be installed: krb5-locales70 packages upgraded, 0 newly installed, 0 to remove and 168 not upgraded.Need to get 4322 kB/136 MB of archives. After unpacking 7982 kB will be used.Do you want to continue? [Y/n/?]Get: 1 http://www.deb-multimedia.org/ testing/main libavutil51 i386 8:1.0.5-dmo1 [111 kB]Get: 2 http://www.deb-multimedia.org/ testing/main libmp3lame0 i386 1:3.99.5-dmo2 [338 kB]Get: 3 http://www.deb-multimedia.org/ testing/main libpostproc52 i386 8:1.0.5-dmo1 [79.6 kB]Get: 4 http://www.deb-multimedia.org/ testing/main libswscale2 i386 8:1.0.5-dmo1 [126 kB]Get: 5 http://www.deb-multimedia.org/ testing/main libtag1-vanilla i386 1.8-dmo1 [257 kB]Get: 6 http://www.deb-multimedia.org/ testing/main libtag1c2a i386 1.8-dmo1 [9396 B]Get: 7 http://www.deb-multimedia.org/ testing/main gstreamer0.10-ffmpeg i386 1:0.10.13-dmo1 [3402 kB]Fetched 4322 kB in 35s (121 kB/s) E: Failed to fetch http://www.deb-multimedia.org/pool/main/f/ffmpeg-dmo/libavutil51_1.0.5-dmo1_i386.deb: Hash Sum mismatchE: Unable to correct for unavailable packages

попробуйте использовать apt-get:

apt-get cleanrm -rf /var/lib/apt/lists/*apt-get cleanapt-get updateapt-get upgrade

Если удалить /var/lib/apt/lists/* не работает…
(экстрасенсорное восприятие. если вы за прокси),исправить “несоответствие хэш-суммы”, как это:

создать файл/и т. д./кв/АПТ.conf.d / 99fixbadproxy
с этим содержанием

Acquire::http::Pipeline-Depth 0;Acquire::http::No-Cache true;Acquire::BrokenProxy true;

см. также здесь

В моем случае такое решение не работает для меня:

  • /var/lib/apt/lists/*
  • изменение серверов на “основной сервер” (или какой-либо другой сервер foreing)

у меня все еще был тот же репозиторий, дающий мне ошибку “несоответствие хэш-суммы”.

я решил попробовать это решение:

  1. перейдите в раздел “программное обеспечение и обновления”
  2. снимите все репозитории из раздела “программное обеспечение Ubuntu”
  3. выберите Раздел “аутентификация”
  4. удалить все записи
  5. сделать sudo apt update (без репозиториев это должно закончиться очень скоро)
  6. повторно откройте “программное обеспечение и обновления” – > “Ubuntu Software” и повторно проверьте все необходимые репозитории
  7. С sudo apt update

удачи.

обновление apt с sudo apt-get install apt

иногда обратный прокси(apache,nginx,…) и сеть сделает контрольную сумму, мы можем попробовать HTTP-прокси другого региона, чтобы решить проблему:

apt-get update -o Acquire::http::Proxy=”$HTTP_PROXY” -o Debug::Acquire::http=true

я столкнулся с аналогичной проблемой

Get:1 http://in.archive.ubuntu.com/ubuntu artful/main amd64 openjdk-8-jre-headless amd64 8u144-b01-2 [27.3 MB] Err http://in.archive.ubuntu.com/ubuntu artful/main amd64 openjdk-8-jre-headless amd64 8u144-b01-2 Hash Sum mismatchHashes of expected file: – SHA256:46924d3fdb329b18b652bc3410f1f2c92ef1259b9a7d66bb1c5d3804b42a8c1c – SHA1:0097b24ef75249d381c7c3f36b36593720c15e [weak] – MD5Sum:1ff35c4d8a2bed71dceba105801cf567 [weak] – Filesize:27256930 [weak]Hashes of received file: – SHA256:ea6892eb6ce7cdc1674a46719302cdbf1b9d485e36bccd27247591527423bb6d – SHA1:8c19dc9f534d8d3c304374bf0c8e7b05cb620b [weak] – MD5Sum:1ff35c4d8a2bed71dceba105801cf567 [weak] – Filesize:27256930 [weak]Last modification reported: Sat, 30 Sep 2017 20:08:32 +0000

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

шаги, которые я следовал:1. grep для ожидаемого в /var/lib/apt/lists

sudo grep 46924d3fdb329b18b652bc3410f1f2c92ef1259b9a7d66bb1c5d3804b42a8c1c *

  1. в моем случае это был

    внутри.архив.ubuntu.com_ubuntu_dists_artful_main_binary-amd64_Packages

  2. заменил хэш-значения ожидаемого файла хэш-значениями полученного файла.

  3. обновление прошло.

У меня была аналогичная проблема при установке пакета Tizen GBS.

мне помогло только приведенное ниже Решение:

  1. вручную загрузить пропустил *.deb пакеты
  2. копировать пакеты в/var/cache/apt / archives
  3. снова запустите команду установки

в этом случае инструмент apt сначала проверяет локальную доступность пакета.Если он присутствует под/var/cache / apt / archives path, то шаг загрузки (с хэш-суммой ошибка несоответствия) пропускается.

пример:

wget http://download.tizen.org/tools/latest-release/Ubuntu_16.04/amd64/librpm-tizen_4.11.0.1.tizen20140530-tizen20140723_amd64.deb sudo cp librpm-tizen_4.11.0.1.tizen20140530-tizen20140723_amd64.deb /var/cache/apt/archives

Источник: https://askdev.ru/q/nesootvetstvie-hesh-summy-paketov-debian-apt-86217/

Больше никаких Hash Sum Mismatch

Sha1sum mismatch

Разработчики недавно нас порадовали ускорением работы apt утилиты и вот ещё подарок – изменение в нашем общении с репозиториями.

Формат Debian репозитория был разработан очень давно. Самые старые его версии создавались через dpkg-scanpackages и забирали мы их через метод dselect по имени dpkg-ftp.

Забирался файл Packages (возможно сжатый) и использовался в качестве индекс-файла, который отражал доступные пакеты. Каждый пакет имел контрольную сумму MD5, чтобы вы могли сверить наличие/отсутствие проблем при передаче.

В те далёкие года ещё не было цифровой подписи у репозитория или какой-либо другой защиты от “человек посередине” (Man in the middle (MITM)).

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

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

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

Формат репозитория со временем эволюционировал под влиянием требований различных клиентских инструментов. В какой-то момент времени был добавлен индекс Sources для пакетов с исходниками программ по аналогии с Packages. Но значительным изменением в структуре репозитория стало внедрение проекта package pools.

Первоначальная схема подразумевала размещение пакетов в dists/ вместе с индексными файлами.

Дерево dists/ создавало программные наборы (suite), современные примеры которых вы знаете по таким именам как stable, stable-updates, testing, unstable, xenial, xenial-updates.

Это означало, что выпуск релиза Debian вынуждал копировать огромные массивы данных и делало реализацию testing очень затратной.

Package pools решили эту проблему перемещением отдельных файлов пакетов из dists/ в pool/, позволяя различным программным наборам (suite) делить между собой один и тот же пакет. Это позволило значительно снизить расходы дискового пространства и пропускную способность при зеркалировании репо.

Как часть этого проекта, первоначальный скрипт dinstall, обслуживающий Debian репозиторий, был заменён на da-katie (dak), который использовал apt-ftparchive для построения индексных файлов. Были заменены dpkg-scanpackages, dpkg-scansources.

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

Спустя пару месяцев после первой реализации package pools, были добавлены файлы Release.

Они образовывали своего рода мета-индексы для каждого программного набора (suite), объясняя APT какие индексы доступны (main/binary-i386/Packages, non-free/source/Sources и т.д) и какие у них контрольные суммы. Реализация подписей (Release.

gpg) позволило безопасно получать пакеты и проверять их на стороне клиента с помощью ключа репозитория. Данная структура репозитория оставалась неизменной многие годы.

В какой-то момент времени все те кто обслуживают хранилища пакетов начали осознавать, что потеряли важное свойство первоначального формата репозитория – отсутствие состояния гонки при обновлении (race-free).

Но после введения файла Release это было утеряно. Клиент должен вначале скачать (fetch) Release и другие индексные файлы, обычно в отдельных HTTP транзакциях.

Если клиенту не повезло и он попал в момент обновления репо, то транзакции будут завершены с ошибкой и он получит Hash Sum Mismatch.

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

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

Apt инструмент и репозитории Debian и Ubuntu поддерживают нововведение. Изменение других индексных файлов сложнее, хотя делать для них inline-signed версию необязательно, так как клиенты обычно забирают малую часть доступных индексов, доступных в данном программном наборе.

Окончательно решение проблемы было закончено благодаря работе Майкла Фогта (Michael Vogt). Его реализация в Apt по имени by-hash будет понятна людям, знакомые с работой git. Индексные файлы для программных наборов (suite) поддерживают механизм by-hash, который позволяет получить (fetch) их, используя URL-хэш. То есть клиент может использовать:

  • Fetch dists/xenial/InRelease
  • Fetch dists/xenial/main/binary-amd64/by-hash/SHA256/46316a202cdae76a73b555414741b11d08c66620b76c470a1623cedcc8a14740
  • Fetch отдельный файл пакета

Все новшества доступны только в Ubuntu 16.04, так как ранние версии не имеют нужного в apt. Теперь Hash Sum Mismatch должны остаться в прошлом.

Есть люди, которые не получат выгоды от новшеств. Debmirror не поддерживает by-hash. Apt-cacher-ng поддерживает в Ubuntu 16.04. Полное зеркалирование репозитория должно происходить так: файлы by-hash должны быть скопированы ДО InRelease.

Настоятельно рекомендуется двухступенчатое зеркалирование. Ubumirror требует доработки. Дебиановский ftpsync работает почти правильно, но нуждается в маленьком твике, который послан разработчикам.

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

Если что-то происходит по вашему мнению странное, то выполните apt -o Debug::Acquire::http=true update для отладки происходящего.

Оригинал No more Hash Sum Mismatch errors
APT станет быстрее.
С apt-get ни шагу назад.

Дата последней правки: 2016-05-22 20:35:54

Источник: http://vasilisc.com/hash-sum-mismatch

Как проверить контрольную сумму файла и почему это важно

Sha1sum mismatch

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

В данной статье рассматривается то, как проверить контрольные числа MD5, SHA256 или SHA512/ SHA1 криптовалютного кошелька, программы, архива или любого другого файла.

Проверка контрольных значений MD5, SHA

В архивах программ, скачанных с интернета разработчики, как правило, вкладывают кроме исполнительных файлов (.exe) еще и .md5sum и.sha256sum-файлы (могут использоваться также ключи с другими цифрами, например, SHA512).

Пример контрольных сумм SHA-1, 256 и 512 для архива программы PhoenixMiner версии 4.5c:

File: PhoenixMiner_4.5c_Windows.zip===================================SHA-1: 2bea8b5d04734fd707ec59b3955e864712e66a91SHA-256: 78300370043207516c8b8a48b20b7040b82203f9d311b6cc28890a934df74fae

SHA-512: 10e4e0ec5db2998fc54673f3b20f751845b6113869087e6e6cd3b3e6c464d00756bc16663414f80dd826d404e2ea71f4df5dc3c59073c97cc9bb7a73bb1d2786

Скриншот этой информации на сайте bitcointalk:

Информация о контрольных суммах, как правило, содержится в архивах/страницах для скачивания файлов. Например, для PhoenixMiner в файловом хранилище mega содержится файл …_checksums.txt:

Зачем программисты вкладывают контрольные суммы исполняемых файлов в репозитории и на сайтах?

Хеши (контрольные суммы) вида SHA1, 256, 512 и MD5 нужны для того, чтобы обезопасить пользователей, скачавших исполняемые файлы из интернета. Они подтверждают целостность и безопасность файла, который предоставляется на ресурсе. Каждый скачивающий этот файл может проверить его целостность, сверив контрольные суммы с теми, которые закодированы в программе.

Это значительно увеличивает уровень безопасности и надежность работы.

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

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

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

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

В настоящее время алгоритм MD5 является устаревшим, так как он имеет ряд существенных недостатков, ухудшающих надежность и предоставляющих хакерам потенциальную возможность взлома.

В связи с этим рекомендуется ориентироваться на контрольные суммы стандартов SHA.

Пример контрольной суммы SHA256 на странице загрузок официального сайта Monero:

В узловом программном обеспечении Bitcoin используются подписи релиза (release hashes). Это asc-файлы, которые обычно включают в себя информацию об SHA-256 хешах и подпись, зашифрованную PGP-ключом.

Скриншот сайта Bitcoin.org с ифнормацией о контрольных суммах Bitcoin Core:

Как на практике проверить контрольную сумму файла?

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

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

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

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

Проверка контрольной суммы заключается в последовательном проведении следующих шагов:

  1. Открывается программа PowerShell входящий в состав Windows.

Чтобы запустить программу PowerShell нужно перейти в каталог со скачанной программой, а затем одновременно нажать кнопку SHIFT + правую кнопку мыши и в появившемся диалоговом окне выбрать открыть PowerShell:

Это же окно в русскоязычной версии Windows:

  1. Затем нужно напечатать в консоли PowerShell команду “dir” (без кавычек) и нажать ввод. В результате этого на экране появится список файлов, содержащихся в директории.

Пример работы с программой PowerShell по проверке контрольной суммы исполняемого файла PhoenixMiner:

  1. Для проверки контрольной суммы MD5 нужно выделить и скопировать (нажав CTRL + C) название нужного файла (в данном случае PhoenixMiner.exe):
  1. Проверяют контрольную сумму файла.

Для проверки контрольной суммы MD5 вводят команду вида:

CertUtil -hashfile название файла MD5

Для проверки контрольной суммы SHA256 вводят команду вида:

CertUtil -hashfile название файла SHA256

В случае проверки Феникс майнера разработчик предоставляет только информацию о checksum zip-архива с программой и сопутствующими файлами:

Для проверки архива с расширением zip вводится команда вида:

CertUtil -hashfile PhoenixMiner_4.5c_Windows.zip SHA256

и нажимается ввод.

В результате успешной проверки контрольной суммы архива PhoenixMiner_4.5c_Windows.zip появится следующая информация:

Как видно, контрольная сумма 78300370043207516c8b8a48b20b7040b82203f9d311b6cc28890a934df74fae, полученная в результате проверки, совпадает с той, которая выложена разработчиком PhoenixMiner на сайте bitcointalk:

Для проверки сумм SHA512 или SHA1 вводятся соответственно команды:

CertUtil -hashfile PhoenixMiner.exe SHA512

или

CertUtil -hashfile PhoenixMiner.exe SHA1.

Заключение

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

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

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

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

Источник: https://www.cryptoprofi.info/?p=3486

Метод повторного хеширования: разница между SHA-1, SHA-2 и SHA-256 алгоритмами хеширования

Sha1sum mismatch
SHA-1, SHA-2, SHA-256, SHA-384 – что всё это значит!? Если вы слышали о «SHA» в множестве его форм, но до сих пор полностью не уверены в том, что означает эта аббревиатура или почему это так важно, то мы попытаемся пролить немного света на эту тему сегодня.

Прежде чем мы коснемся самого SHA, нам нужно узнать, что такое хеш, рассмотреть, как SSL-сертификаты используют хеш для формирования цифровых подписей. Это важные концепции, которые важны для понимания до того, чем вы сможете разобраться, что такое SHA-1 и SHA-2. Давайте начнем.

Алгоритм хеширования — это математическая функция, которая сокращает данные до фиксированного размера.

Так, например, если бы мы взяли предложение «Быстрая Коричневая Лиса Прыгает Через Ленивую Собаку» И прогнали его через специальный алгоритм хеширования, известный как CRC32, мы бы получили следующий результат: «07606bb6». Этот результат называется хеш или хеш-значением.

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

Одним из ключевых свойств алгоритмов хеширования является детерминизм. Любой компьютер в мире, который понимает алгоритм хеширования, который вы выберете, может локально вычислить хеш предложения из нашего примера и получить тот же самый ответ. Алгоритмы хеширования используются всевозможными способами – они используются для хранения паролей, в базах данных и т.д. Существуют сотни алгоритмов хеширования и все они имеют конкретные цели – некоторые из них оптимизированы для определенных типов данных, другие для обеспечения высокой скорости, третьи – безопасности и т.д. В сегодняшнем разборе нас интересует только SHA алгоритм. SHA расшифровывается как Защитный алгоритм хеширования – его название уже говорит само за себя – он используется для криптографической защиты. Криптографические хеш-алгоритмы производят необратимые и уникальные хеши. Необратимость состоит в том, что, если бы у вас был только хеш, вы не смогли бы его использовать, чтобы выяснить, каков был исходный фрагмент данных, поэтому исходные данные остаются безопасными и неизвестными. Уникальность означает, что две разных части данных никогда не могут превратиться в один и тот же хеш – в следующем разделе объясним, почему это так важно.

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

Теперь, когда мы знаем, что такое хеш, мы можем объяснить, как он используется в SSL-сертификатах. Протокол SSL/TLS используется для обеспечения безопасной передачи данных с одного устройства на другое через Интернет. Для краткости создается впечатление, что SSL часто понимается, как шифрование. Однако не забывайте, что SSL обеспечивает также аутентификацию. В файле сертификата SSL задается необходимая информация, которая необходима для аутентификации. Или, другими словами, SSL-сертификаты связывают определенный открытый ключ с идентификатором. Запомните, что SSL/TLS протокол способствует соединению с использованием асимметричного шифрования. Это означает, что есть два ключа шифрования, каждый из которых обрабатывает половину процесса: открытый ключ для шифрования и закрытый для дешифровки. Каждый сертификат SSL содержит открытый ключ, который может использоваться для шифрования данных клиентом, а владелец указанного SSL-сертификата надежно хранит закрытый ключ на своем сервере, который они используют для дешифрования данных и делает их доступными для чтения. В конечном счете, основной целью асимметричного шифрования является безопасный обмен ключами. Асимметричные ключи требуют большой вычислительной мощности, поэтому они также используют (и все еще безопасно) небольшие симметричные ключи для фактической части соединения. Таким образом, клиент генерирует сеансовый ключ, шифрует его копию и отправляет ее на сервер, где он может быть расшифрован и использован для связи в течение всего времени соединения (или до его поворота). Именно поэтому аутентификация невероятно важна для обеспечения того, чтобы SSL/TLS фактически обеспечивал значимую безопасность. Представьте, что ваш компьютер не имел бы надежного способа узнать, кому принадлежит ключ шифрования, который вы использовали? Шифрование ключа сеанса с помощью такого ключа не будет полезным, потому как вы не знаете, кто владеет соответствующим закрытым ключом, который его расшифрует. В конце концов, шифрование данных малопригодно, если вы отправляете его непосредственно злоумышленнику, посреднику злоумышленника на другом конце провода.

Цифровые подписи являются важной частью того, как SSL-сертификаты предоставляют аутентификацию. Когда выдается сертификат, он подписывается цифровой подписью центром сертификации (CA), выбранным вами в качестве поставщика сертификатов (например, Sectigo, Thawte, Geotrust и т.д.).

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

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

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

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

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

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

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

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

Если на вашем компьютере обнаружена недопустимая подпись, это приведет к ошибке и полностью предотвратит небезопасное соединение.

Теперь, когда нами заложенфундамент ваших знаний, можем переходить к звезде сегодняшнего шоу.  Как уже говорилось выше, SHA – это защитный алгоритм хеширования. SHA-1 и SHA-2 – это две разные версии этого алгоритма. Они различаются в конструкциях (как создается хеш из исходных данных) и в битовой длине подписи. Вам следует воспринимать SHA-2, как преемника SHA-1.

В первую очередь, люди сосредоточены на бит-длине, как на важном различии. SHA-1 — это 160-битный хеш. SHA-2, на самом деле, является «семейством» хешей и имеет множество длин, наиболее популярной из которых является 256-бит. Разнообразие хешей SHA-2 может привести к путанице, поскольку сайты и авторы обозначают их по-разному.

Если вы видите «SHA-2», «SHA-256» или «SHA-256 бит», эти имена относятся к одной и той же вещи. Если вы видите «SHA-224», «SHA-384» или «SHA-512», это относится к чередованию бит-длины SHA-2. Вы также можете увидеть, что некоторые сайты выписывают как алгоритм, так и длину бита, например «SHA-2 384.».

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

С 2011 по 2015 год SHA-1 был основным алгоритмом. Растущее число исследований, показывающих недостатки SHA-1, вызвало переоценку. Фактически, Google даже зашел так далеко, что создал конфликт SHA-1 (когда две части разрозненных данных создают одно и то же значение хеш-функции). Таким образом, с 2016 года SHA-2 является новым стандартом. Если вы получаете сегодня сертификат SSL/TLS, он должен использовать эту подпись. Иногда вам будут встречаться сертификаты, использующие SHA-2 384-бита. Реже будут встречаться 224-битные типы, поскольку они не одобрены для использования с публично доверенными сертификатами, или 512-битные типы, которые очень редко поддерживаются программным обеспечением. SHA-2, вероятно, останется актуальным еще не меньше, чем на 5 лет. Тем не менее, можно ожидать и некоторую атаку на алгоритм, которая вызвала бы более ранний переход. Вот хеш SHA-1 и SHA-2 сертификата SSL сайта выглядят так: Это то, о чем и шла речь. Возможно, это не так много, но цифровые подписи невероятно важны для обеспечения безопасности SSL\TLS.

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

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

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

Если алгоритм хеширования должен создавать уникальные хеши для каждого возможного ввода, сколько всего возможных хешей? Бит имеет два возможных значения: 0 и 1. Возможное количество уникальных хешей может быть выражено как количество возможных значений увеличенных на количество бит. Для SHA-256 имеется 2 256 возможных комбинаций. Итак, 2 256 комбинаций. Сколько это? Ну, это огромное количество. Шутки в сторону. Это делает цифры, подобные триллиону и септилию, ничтожными. Это намного превышает количество зерен песка в мире. Чем больше число возможных хешей, тем меньше вероятность того, что два значения создадут один и тот же хеш. Обратите внимание, что большая длина бит вовсе не означает, что алгоритм хеширования производит более безопасный хэш. Построение алгоритма также невероятно важно – поэтому индустрия SSL использует алгоритмы хеширования, специально разработанные для криптографической защиты. В 2015 году индустрия SSL прошла «переход на SHA-2». Это включало повторную выдачу тысяч существующих сертификатов, чтобы новые файлы могли быть созданы и подписаны с SHA-2. Это также связано с крупными обновлениями программного обеспечения для выпуска, которым работают централизованные доверенные центры сертификации (их десятки). Как и ожидалось, были сбои. Крайний срок для выдачи новых SSL сертификатов с SHA-1 был назначен на 31 декабря 2015. По большей части, выдача была осуществлена к назначенному сроку. С тех пор было сделано несколько ошибок, и произошло несколько особых случаев. Но за последние три года сертификаты SHA-1 почти полностью исчезли. Сегодня, если вы столкнулись с сертификатом SHA-1, вы увидите предупреждение. В Google Chrome все сертификаты SHA-1, срок действия которых истекал в 2016 году, не показывали зеленый замок в защищенных соединениях и вместо этого отображали тот же значок, что и незащищенное HTTP-соединение. Вы можете щелкнуть на значок, чтобы получить более конкретную информацию о том, почему он отображается, если есть другие причины, не связанные с подписью. Браузеры обрабатывали подписанные сертификаты SHA-1, срок действия которых истекал в 2017 году с более интенсивным предупреждением. Это связано с тем, что безопасность подписи напрямую связана с тем, как долго она действительна.

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

По прошествии времени атаки на криптографию станут лучше, а мощность компьютерной обработки станет дешевле. Это делает действительную подпись SHA-2 менее безопасной в 2020 году, чем в 2016 году. По этой причине выбирать придется еще более сильный алгоритм, чем это необходимо, чтобы краткосрочные улучшения не привели к компрометации безопасности в будущем. Для алгоритма хеширования нереально не оставаться в безопасности на протяжении десятилетия. Отраслевые эксперты и исследователи безопасности во всем мире постоянно анализируют алгоритмы SHA-2 и другие криптографические алгоритмы хеширования, поэтому будьте уверены, что SSL-сертификаты будут иметь надежные и безопасные цифровые подписи на протяжении какого-то времени. Это не означает, что криптографы будут просто сидеть и ждать, пока не возникнет проблема. Преемник SHA-2, удобно названный SHA-3, уже создан. Когда придет время сделать другой коммутатор, индустрия SSL может использовать SHA-3 в качестве своего следующего выбора, или сможет воспользоваться совершенно другим алгоритмом. Требуются годы, чтобы правильно исследовать и проверять новые криптографические стандарты, а затем разрабатывать программное обеспечение, которое их поддерживает. Надеюсь, это обнадеживает, потому что вы знаете, что индустрия всегда, по крайней мере, на один шаг впереди.

Источник: https://www.emaro-ssl.ru/blog/%D0%BC%D0%B5%D1%82%D0%BE%D0%B4-%D0%BF%D0%BE%D0%B2%D1%82%D0%BE%D1%80%D0%BD%D0%BE%D0%B3%D0%BE-%D1%85%D0%B5%D1%88%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F-%D1%80%D0%B0%D0%B7%D0%BD%D0%B8%D1%86/

Поделиться:
Нет комментариев

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

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