С самого начала http/html протокол интернета передавал по сети все данные без всякого кодирования информации. И наверное в каждом пункте провайдеров интернета тогда сидели так называемые "слухачи", которые с помощью специальных программ прослусушивания трафика просматривали все передаваемые и/или получаемые данные с целью получения хоть какой личной выгоды. И в частности около 20+- лет назад я лично был свидетелем, как через наш корпоративный сайт кто-то скачал целый фильм из серии про Джеймса Бонда. Не смейтесь только. Просто в то время входящий трафик был настолько дорог, что этот никчемный на мой взгляд фильм обошелся компании в весьма ощутимую и обидную сумму. Ну и естественно руководство произвело свое собственное расследование. Оказалось в результате, что фильм оказался и в самом деле скачанным, и его файл реально располагался в одном из оглавлений нашего линухового веб-сервера. Так что оспаривать этот факт с провайдером интернета было абсолютно бесполезно.
Выяснилось, что такое мог проделать только тот исключительно, кому знаком администраторский логин и пароль сервера. А эти сведения были известны только одному человеку, подозревать которого было бы нелепо и смешно, так как он приходился сыном директору. К тому же скачивание происходило глубокой ночью, когда все сотрудники компании мирно спали надо полагать каждый у себя дома.
Чтобы понять, как злоумышленники заполучили админский доступ к серверу, я обязан немного уточнить кое-какие детали. Дело в том, что наша компания была аутсоурсинговой. Для тех, кто не знает, что это такое поясню, что главный босс компании располагался в США, а мы все пахали на него в России. И в какой-то момент боссу вдруг зачем-то очень захотелось знать атрибуты админского доступа к своему собственному российскому веб-серверу. А общение с ним тогда велось в основном через электронную почту. Ну вот ему и передали по его же требованию через электронное письмо ту информацию, которую он так жаждал знать. Ладно бы это было сделано через смс, что было тогда уже возможно. Ну и результат этого я уже описал выше. Просто других вариантов утечки секретной информации нет.
Ну, а сейчас мы все уже можем радоваться и ликовать, что почти вся информацию передается через отрытую сеть в зашифрованном виде. Так что теперь ваши секретные пароли и параметры доступа к банковским карточкам в полнейшей безопасности. Кстати, алгоритм шифрования SSL не только повсеместно одобрен во всем мире, но и его исходные программные коды на языке С вообще общедоступны в интернете. Так что, кому не лень, скачивайте и пользуйтесь. Кстати, мне лично по ходу моей профессиональной деятельности и в самом деле довелось разок воспользоваться этим общедоступным программным кодом. Причем это было так давно, когда эти технологии шифрования в интернете лишь только входили в моду.
И вот тогда же у меня и возникли некоторые первые сомнения. Прежде всего подумайте сами, что зашифрованные данные передаются через сеть, и прочесть их напрямую невозможно. Да, это и в самом деле правда. Но ведь почтовые клиенты (напр. Microsoft Outlook и все остальные) и обозреватели интернета (напр. Яндекс Обозреватель и все остальные) все-таки принимают эту зашифрованную информацию, расшифровывают ее и отображают ее в конечном счете на ваших экранах в исходном виде. Так почему это вдруг одни могут расшифровать сложно закодированную информацию, а другие - нет? Так вот, забегая немного вперед, скажу, что не могут расшифровать эту кодировку лишь самые ленивые, кому в лом подключить общедоступный вышеупомянутый мною алгоритм SSL.
Для кодирования какого-либо сообщения там используются два ключа: открытый и закрытый. И в результате такого кодирования отдельные биты сообщения перемешиваются так замысловато, что восстановить оригинал становится практически невозможно. Правда, когда квантовые компьютеры достигнут достаточной мощности, то такая расшифровка займет лишь считаные секунды. Но, пока они этого не достигли, то может показаться, что вся ваша информация, проходящая через открытую сеть, в полной безопасности. Однако даже квантовые компьютеры на самом деле тут не нужны, поскольку достаточно для расшифровки вашего сообщения лишь открытого ключа. И этот ключ в открытом виде (что очевидно из его названия) и передается в защищенных интернетовских протоколах (напр. HTTPS). И именно его используют все легальные интернетовские приложения для расшифровки закодированных данных.
Что, не верится? Я тоже поначалу сильно прибалдел, когда впервые узнал об этом. У меня есть один товарищ, который более компетентен в вопросах шифрования, чем я. Я когда-то спросил у него: а в чем дескать польза от такого шифрования? И с большим удивлением для меня он ответил: "Ну да, данные расшифровать может, кому не лень. Но он ведь без закрытого ключа не сможет их изменить и передать дальше в искаженном виде.". Так что, уважаемые сограждане и заодно уж и иностранцы, не волнуйтесь, передавая свои секретные сообщения через защищенные каналы - их никто не сможет изменить или исказить.
История №1435091
+-19–
Проголосовало за – 18, против – 37
Статистика голосований по странам
Статистика голосований пользователей
Чтобы оставить комментарии, необходимо авторизоваться. За оскорбления и спам - бан.
35 комментариев, показывать
сначала новые
сначала новыесначала старыесначала лучшиеновые - список
Глупость написана.
Асимметричное шифрование работает в две стороны: можно зашифровать информацию закрытым ключом, и её расшифрует любой владелец открытого ключа, но никто не сможет подменить (так работает электронная подпись), а можно зашифровать информацию открытым ключом, и её расшифрует ТОЛЬКО владелец закрытого ключа.
Так вот, по протоколу SSL сначала СЕРВЕР передаёт клиенту свой сертификат (открытый ключ + реквизиты организации + подпись доверенного центра сертификации), который гарантирует, что клиент подключился именно к этому серверу, а не постороннему промежуточному устройству.
Затем КЛИЕНТ создаёт симметричный временный ключ шифрования, шифрует его открытым ключом сервера и отправляет на сервер. Сервер получает ключ, расшифровывает его (а без закрытого ключа никто больше сможет расшифровать эту информацию) и подтверждает готовность обмениваться данными по временному ключу.
Всё. Теперь симметричный временный ключ имеют ТОЛЬКО сервер и клиент, и они шифруют/расшифровывают им всё, что идёт через открытые каналы связи. При этом сеансы связи с разными клиентами используют разные временные ключи - у каждого клиента свой временный ключ, который нигде не хранится (только в оперативной памяти во время сеанса связи) и даже во время сеанса периодически меняется.
+3–
ответить
atanewtion➦El Scorpio• 01.01.24 20:29
Как все сложно в этой жизни. Однако все это не объясняет, почему все обозреватели интернета расшифровывают полученную от веб-сервера информацию, а другим приложениям это якобы недоступно?
Я бы лично на спор естественно на крупную денежную сумму взялся бы за эту "неразрешимую" задачу. Так что, может поспорим? Но с задатком хотя бы в 50%.
+0–
ответить
El Scorpio➦atanewtion• 01.01.24 20:42
Потому что информация в процессе передачи внутри сеанса SSL шифруется ВРЕМЕННЫМ ключом, который знают только ЭТОТ клиент и сервер.
А вот на сервере полученная информация хранится уже в нешифрованном виде. То есть если отправляешь электронное письмо, то оно шифруется при передаче с компьютера отправителя на сервер отправителя, далее при передаче с сервера отправителя на сервер получателя, и в третий раз при загрузке получателем со своего сервера. При этом на серверах оно хранится в незашифрованном виде, так что ФБР, ЦРУ, АНБ и прочие спецслужбы при подключении к этому серверу прочитают это письмо.
Однако если получатель имеет электронную подпись, можно зашифровать письмо открытым ключом получателя (точнее "конверт" с адресом отправителя, получателя и транспортной историей разумеется не шифруют, но текст сообщения и приложенные файлы будут зашифрованы). Тогда его сможет прочитать ТОЛЬКО владелец закрытого ключа получателя (то есть сам получатель)
+1–
ответить
Сцинк ★➦atanewtion• 01.01.24 22:48
> Я бы лично на спор естественно на крупную денежную сумму взялся бы за эту "неразрешимую" задачу.
Приступайте немедленно, и не нужен вам никакой спор! За способ взлома https вам IT-гиганты отвалят много миллионов долларов, не торгуясь!
+1–
ответить
atanewtion➦Сцинк• 01.01.24 23:41
Ну все-таки, а почему все обозреватели интернета расшифровывают каким-то образом кодировку RSA, а другим лохам это не дано? Ну просто так, задумайтесь?
+0–
ответить
Сцинк ★➦atanewtion• 01.01.24 23:55
Ну окей, так вломайте уже https и получите заслуженную славу и богатство! Покажите всему миру какой вы умный, и какие все остальные дураки! Что вы тут вместо этого с нами дураками переписываетесь?
+1–
ответить
Civilian➦atanewtion• 02.01.24 03:34
Потому что секретные ключи никогда не покидают приложение и не передаются никуда. А математика гарантирует, что на современной технике вы не расшифруйте перебором данные даже за год даже на суперкомпьютерах (на самом деле там десятилетия на расшифровку, притом что ключ меняется периодически и надо на каждый ключ весь процесс заново)
+0–
ответить
HelgeS➦El Scorpio• 22.01.24 17:22
Совершенно верно. Глупость полная.
Если изложить попроще, то шифруются данные на открытом ключе, а расшифровываются на закрытом, а ЭЦП, наоборот, генерируется на закрытом, а проверяется на открытом.
таким образом расшифровать сообщение может только тот, на кто предоставил для этого свой открытый ключ и имеет у себя закрытый, а проверить подпись может кто угодно, кто имеет доступ к открытому ключу подписанта.
в случае с почтовым сервером шифруется именно трафик между клиентом и сервером, а не само сообщение. хранится оно на сервере, в общем случае, в открытом виде.
если требуется обеспечить именно шифрование енд-то-енд, то нужно шифровать само сообщение. тогда оно будет передаваться на сервер и храниться там уже зашифрованным, а в процессе передачи будет шифроваться еще раз "поверх". а что бы его прочесть потребуется закрытый ключ адресата. при этом отправитель его уже не сможет прочесть.
+0–
ответить
Хрень какая-то. Автор или троллит, или реально не понимает как работает асимметричное шифрование. Дело в том, что открытого ключа абсолютно недостаточно для расшифровки сообщения - нужен приватный ключ того, кому сообщение адресовано. А он, понятно, никуда через сеть не передается.
Кто хочет узнать подробнее - гуглите "RSA" (ведь SSL - это не алгоритм, как написал автор, это протокол, который может использовать разные алгоритмы, например RSA).
+4–
ответить
Пустая полка➦Сцинк• 01.01.24 10:43
Автор перепутал шифрование, которое производится открытым ключём (а дешифровка закрытым и цифровую подпись.
В этом случае все наоборот: подпись вычисляется при помощи закрытого ключа, а проверка того, что документ не изменился - при помощи открытого.
Бывает.
+2–
ответить
atanewtion➦Сцинк• 01.01.24 12:48
Ну, допустим. А как тогда к примеру происходит дешифровка любым обозревателем интернета? Какой закрытый ключ должен использовать веб-сервер для шифрования, чтобы потом кто-то мог расшифровать?
+0–
ответить
Сцинк ★➦atanewtion• 01.01.24 13:28
Я же написал - гуглите "RSA". Или, точнее, "как работает RSA". Полно статей, где всё разжёвано.
+0–
ответить
Civilian➦atanewtion• 01.01.24 16:45
atanewtion, почитайте не про RSA, а про Диффи-Хеллмана.
Если упрощенно говорить, то публичный ключ это два числа (одно из них - огромное простое число, их принято обозначать буквами p и g). Первая сторона берет новое число a (секретное), вторая - новое число b, как ключи шифрования. Чтобы договорится о новом ключе шифрования (уже симметричном), первая сторона передает другой результат число A - "остаток от деления (g в степени a) на p" (g^a % p), вторая соответственно чисто B - "остаток от деления (g в степени b) на p". Внешний наблюдатель видит только остатки от деления, в то время как обе стороны теперь знают и a и b и вычисляют новый общий ключ по формуле "остаток от деления (B в степени a) на p" (соответственно A в степени b для другого) - получается один и тот е ответ, но вычислить его не зная a или b и просто прослушивая - займет уйму времени.
Теперь наведем на это еще один уровень сверху и весь обмен зашифруем ассиметричным алгоритмом (RSA вам выше привели в пример) - это фактически такая математическая функция, которая позволяет зашифровать сообщение одним из ключей, но расшифровать его только имея второй ключ (то есть клиент может зашифровать сообщение публично доступным ключом и сервер его расшифрует, и наоборот).
И в итоге у сервера и клиента получается ключ, защищенный от перехвата сторонним наблюдателем, который потом можно использовать для простых и дешевых симметричных алгоритмов шифрования.
А зачем их оба? Потому что если какая-то зловредная организация будет записывать все общение и потом сможет его расшировать (например надеясь украсть ключи), им все равно придется еще раз переподбирать ключи каждый раз как они меняются (а они меняются часто).
Если что я не претендую на полное и точное объяснение в комментах, но надеюсь это даст нужный набор ключевых слов для поиска информации.
+1–
ответить
El Scorpio➦atanewtion• 01.01.24 20:49
Ещё раз: при создании сеанса SSL клиент сам придумывает шифрует временный пароль для этой сессии, шифрует открытым ключом сервера и передаёт шифровку серверу, который расшифровывает её своим закрытым ключом.
А затем клиент и сервер передают друг другу информацию, которую шифруют и расшифровывают этим временным ключом, который никто посторонний не знать не может
+1–
ответить
atanewtion➦El Scorpio• 01.01.24 22:48
Как все сложно в этой нашей жизни. Однако все это не объясняет, почему все обозреватели интернета расшифровывают полученную от веб-сервера информацию, а другим приложениям это якобы недоступно?
Я бы лично на спор естественно на крупную денежную сумму взялся бы за эту "неразрешимую" задачу. Так что, может поспорим? Но с задатком хотя бы в 50%.
+0–
ответить
Пустая полка➦atanewtion• 01.01.24 23:16
С чего вы все это взяли.
Вы азов не знаете, и вместо того, чтобы прочитать это в элементарном изложении, начинаете теории строить.
Программ, которые шифруют и дешифруют полно. Обозреватели интернета (ну и словечко вы придумали) далеко не единственные, кто это умеет делать на лету (не говоря уже про шифрование файлов).
+1–
ответить
Civilian➦atanewtion• 02.01.24 02:25
Ищите гаранта, который возьмёт взнос от вас от того, кто согласится с вами спорить. На какой срок вы хотите? Я без проблем поддержу спор на сумму до 5000$ (в смысле что вы не взломает шифрован е каким либо способом кроме тупого перебора или радужных таблиц)
+0–
ответить
atanewtion➦Civilian• 02.01.24 21:48
Вы как-то неправильно меня поняли. Я совсем не собирался давать какой-то взнос, а совсем наоборот - что-то типа предоплаты за предстоящую работу. И указанная вами сумма маловата на мой взгляд, я взялся бы за работу, если бы эта сумма была как минимум раз в 10 больше.
Тупой перебор мною не планировался изначально по причине очевидной бесперспективности этого. А насчет каких-то радужных таблиц я ничего не знаю и даже нет желания гуглить что-то на этот счет. Я собираюсь сделать это совершенно легально - точно также, как это делают программно все обозреватели интернета.
+0–
ответить
Civilian➦atanewtion• 02.01.24 22:08
Так кто вам даст денег на то, что вы 100% не сделаете? На вас можно нажиться, если вы согласитесь поспорить (и неизбежно проиграете) и только. Вот какой смысл давать вам деньги, если вы не сделаете то, что обещаете? В чем профит того, кто даст?
+0–
ответить
atanewtion➦Civilian• 03.01.24 00:49
И в самом деле профита нет, поскольку я 100%-но выиграю.
+0–
ответить
Civilian➦atanewtion• 03.01.24 00:57
Нет, вы 100% проиграете, в этом и дело. Был бы у вас хоть какой то шанс, то 50к$ за возможность читать любую современную шифрованную переписку, это в общем ничто. Только вы этого не сделаете, а значит кроме спора на деньги с вами ничего не имеет смысла делать
+1–
ответить
atanewtion➦Civilian• 03.01.24 01:21
Ну почему же? Можно было бы составить соответственный договор, который бы имел юридическую силу. Раз уж вы так уверены в своей правоте...
+0–
ответить
Civilian➦atanewtion• 03.01.24 03:06
Лично я не уверен в вашей способности выплатить в разумный срок все уплаченное вам, плюс неустойку сверху. Поэтому и спор с гарантом, где ставки перечисляются гарантам сначала мною и вами и по выявлению победителя эта третья сторона перечисляет деньги тому кто выиграл (за вычетом своей комиссии).
+0–
ответить
atanewtion➦Civilian• 04.01.24 20:26
Первая сторона берет новое число a (секретное), вторая - новое число b, как ключи шифрования.
Да, я тоже уже давно слышал о таком. Но какое это имеет отношение например к протоколу HTTPS? Я недавно из любопытства восполнил в памяти поверхностные сведения об этом протоколе, и там нет ничего подобного. Вместо этого клиент и сервер обмениваются ключами шифрования.
Вероятно мы с вами говорили на разных языках? Я намеревался в подтверждение своей правоты лишь организовать расшифровку html-кода веб страницы с любого защищенного с помощью SSL канала. А вот, интересно, что имели ввиду вы?
+0–
ответить
Civilian➦atanewtion• 04.01.24 21:16
Но какое это имеет отношение например к протоколу HTTPS? <...> Вместо этого клиент и сервер обмениваются ключами шифрования.
Прямое. Diffie-Hellman это механизм установления нового ключа шифрования.
В рамках SSL/TLS сначала коммуникации шифруются ассиметричной криптографией и по этому шифрованному каналу с помощью Diffie-Hellman'а устанавливают новый симметричный ключ шифрования и уже дальше общение идет с его использованием. Если вы посмотрите, как обозначаются шифры, то увидите там строчки вида "TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8" - что говорит что это TLS где симметричный ключ обсуждается с помощью ECDHE (Diffie-Hellman с элиптическими кривыми как выбором чисел), ассиметричное шифрование через DSA на элиптических-кривых и симметричное шифрование идет с использованием AES-128 в режиме CCM-8 (CCM8 это такой вариант AES где шифрование имеет еще и встроенную подпись, чтобы защитить от повреждения данных). Вот ваша проблема в том что вам надо прочитать то, что зашифровано ECDSA а потом найти ключ который был скоммуницирован с помощью ECDHE. Только после этого вы сможете прочитать зашифрованные данные.
с любого защищенного с помощью SSL канала.
Вы в посте говорили о том, что "Однако даже квантовые компьютеры на самом деле тут не нужны, поскольку достаточно для расшифровки вашего сообщения лишь открытого ключа" - то есть речь идет о том, что если вы получите запись какого-то абстрактного https общения то вы можете получить данные, что там передавались. Вот это у вас не получится сделать, потому что математика за ассиметричными алгоритмами не позволяет расшифровать данные имея только открытую часть ключа. То есть ваша попытка добиться того о чем вы говорили сломается на первом же шаге.
+0–
ответить
atanewtion➦Civilian• 04.01.24 22:28
Ну во первых я там перепутал открытый и закрытый ключи. Ну извините уж - давно подзабыл детали.
Но я ведь неоднократно задавал вопрос: почему все обозреватели интернета (Яндекс, Файерфокс, Хром, ЭдЖ и мн. др.) расшифровывают закодированную информацию, а другим программам это якобы недоступно? Чем они лучше других, и почему я не могу создать нечто подобное?
Только поймите меня правильно: я вовсе не жажду этого. Это больше надо тем, кому интересно то, о чем там в народе говорят.
И насчет некоторого абстрактного tcp-ip-пакета, который передается через защищенный канал, я вовсе не говорил, что его можно расшифровать. Наоборот - это практически невозможно. И даже не знаю точно, как тут сможет сработать квантовый компьютер. На самом деле я имел ввиду то, что это возможно лишь при полном перехвате трафика между клиентом и сервером.
+0–
ответить
Civilian➦atanewtion• 04.01.24 23:32
Обозреватели могут расшифровать только то что передано в рамках сессии, потому что они генерируют второй ключ и держат в памяти пока соединение установлено. Соединение закрылось и то что было передано и получено уже никто не расшифрует.
И это не ограничивается браузерами, tls поддерживается кучей приложений, собственно в современном мире это обязательное требование для передачи данных во вне. Но его умеет и почтовый клиент и RDP и SSH и даже мобильная онлайн игрушка (скорее всего только для управляющего трафика)
+0–
ответить
atanewtion➦Civilian• 05.01.24 12:32
Но я как раз и намеревался создать самый простейший обозреватель, способный расшифровать любую веб-страницу.
Обозреватели могут расшифровать только то что передано в рамках сессии, потому что они генерируют второй ключ и держат в памяти пока соединение установлено.
В HTTPS только клиентский обозреватель генерит открытый ключ. А для сервера он формируется на базе URL по определенным правилам.
+0–
ответить
Civilian➦atanewtion• 05.01.24 13:12
Но я как раз и намеревался создать самый простейший обозреватель, способный расшифровать любую веб-страницу.
Я вам выше приводил ваше заявление изначальное. Вы там говорили что можете прочитать любое зашифрованное соединение, так как все ключи для этого есть. Простейший обозреватель даром никому не сдался, так как это достойная работа для не самого толкового студента, притом в зависимости от того сколько вы можете использовать из имеющегося кода, диапазон будет от задания на лабораторную работу до уровня курсача максимум.
В HTTPS только клиентский обозреватель генерит открытый ключ. А для сервера он формируется на базе URL по определенным правилам.
HTTPS есть ни что иное как HTTP over SSL/TLS. Сначала устанавливается обычное TCP соединение, потом устанавливается SSL/TLS шифрование и только потом по полученному шифрованному каналу идут обычные HTTP запросы-ответы. На этапе установления SSL/TLS известен только домен (и то опционально), но не URL. Так что вы не правы.
Проведите простой эксперимент - возьмите wireshark, запишите обмен сообщениями для нескольких разных сессий в браузере но на один URL и посмотрите что внутри, параметры сессии вы увидите, вот только использовать их для расшифровки вы не сможете, так как ключ для симметричного шифрования не передается нигде :)
+0–
ответить
atanewtion➦Civilian• 05.01.24 15:30
По протоколу HTTPS клиент и сервер обмениваются через сокеты своими секретными ключами. А это значит, что прочесть их может любая программа-слухач, анализирующая трафик. Как говорил когда-то герр Мюллер: если что-то известно двоим, то это известно и свинье.
Этот протокол вообще не предусматривает какое-нибудь изменение полученных данных с дальнейшей передачей дальше кому-то еще в сети. Поэтому роль открытых ключей здесь вообще опциональна. По крайней мере с позиций слухача необходимо и достаточно располагать лишь закрытыми ключами, чтобы прочесть зашифрованные данные в оригинальном виде. Естественно слухач не сможет в таких условиях изменить передаваемые по сети данные. Но и расшифровка их - это тоже немало.
+0–
ответить
Civilian➦atanewtion• 05.01.24 16:29
По протоколу HTTPS клиент и сервер обмениваются через сокеты своими секретными ключами.
Вы снова упускаете, что обмен ключами идет в зашифрованном ассиметричным шифром виде. Который математически устроен так, что имея только открытую часть вы не дешифруете сообщение и не восстановите закрытую часть ключа.
с позиций слухача необходимо и достаточно располагать лишь закрытыми ключами
Только закрытые ключи никуда не передаются :) Математически вы можете получить закрытый ключ методом перебора, что займет у вас пару тысяч лет на современном суперкомпьютере. Поэтому вы, будучи слухачем, не можете ни прочитать ни изменить данные. Вам доступны только метаданные (вы знаете название алгоритма шифрования и в некоторых случаях название вебсайта который будет отвечать, на этом все)
+0–
ответить
atanewtion➦Civilian• 05.01.24 19:50
Только закрытые ключи никуда не передаются
Нет смысла спорить об очевидном. Просто гляньте хотя бы в википедию на досуге.
+-1–
ответить
Civilian➦atanewtion• 05.01.24 22:01
Так я вам и пересказываю то, что вы легко найдете в Википедии или стандарте на tls 😉
Я с этим всем, скажем так, знаком не по наслышке. С реализацией и тем как оно работает.
+0–
ответить
Когда ещё не было интернета, смс и прочего, товарищ Мюллер выразил всю предоставленную сейчас историю одним предложением - "Знают двое, знает и свинья".
+0–
ответить