Telegram

[_sv_]

А на чем основана информация о том, что Паша не имеет доступа к ключам и остальному?

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

 

Но если вопрос поставить абстрактно, то ответ может вас удивить.

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

 

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

[Пэтро]

Исходники клиента вроде открыты.

[MedicusAmicus]

А вот исходники сервера - нет.

И, будь они опубликованы - не факт, что именно они крутятся на боевых серверах.

[Инквизитор]

Понятно теперь что вы имели ввиду. Меня ввели в заблуждение предложение шифровать данные самим клиентам (архиваторы и т.д.)

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

И, понятно, речь не о самопальных "пляшущих человечках", а о современных годных алгоритмах, таких, как задействованные в троянах-шифровальщиках.

 

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

Вот тут-то и собака порылась.

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

[KillerSerg]

А вот исходники сервера - нет.

И, будь они опубликованы - не факт, что именно они крутятся на боевых серверах.

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

 

https://core.telegram.org/file/811140633/4/hHw6Zy2DPyQ.109500/cabc10049a7190694f

 

Кстати, как при таком раскладе шифруются многопользовательские конференции, ума не приложу

Многопользовательские не шифруются

[Пакость]

А точнее - по соединению (которое может быть как открытым, так и TLS) идет шифрованный поток данных E2E.

Как вы представляете себе man-in-the-middle в таком ключе?

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

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

 

https://core.telegram.org/file/811140633/4/hHw6Zy2DPyQ.109500/cabc10049a7190694f

Картинка хороша, но таки вот мне до конца оставляет открытым вопрос: "Secret Chat key" в конце концов каким образом доставляется собеседникам, открытым или закрытым?

Изменено 27 апреля, 2018 пользователем Пакость

[KillerSerg]

Картинка хороша, но таки вот мне до конца оставляет открытым вопрос

 

 

Изучайте

https://core.telegram.org/api/end-to-end

 

 

Хотя и по одной картинке ясно, что "Secret Chat key" не передается.

 

 

 

Зы - желающим доказать уязвимость протокола MTProto гарантировались премии в 200к$ и 300к$. Достаточно серьезные призы для bug bounty программы.

https://telegram.org/crypto_contest

https://telegram.org/blog/cryptocontest

[KillerSerg]

Очередной обосрамс от РКН. Пусть и на пару часов по продолжительности, но факт

 

В числе заблокированных:

 

IP Домены на IP

31.13.92.14, 157.240.20.15, 157.240.20.19... facebook.com, m.facebook.com, messenger.com

13.107.21.200 bing.com, m.bing.com, ...

104.244.42.131 twitter.com

104.244.42.5 t.co

2.17.140.47 addthis.com

104.16.18.96 whatismyipaddress.com

37.79.247.8 rnis66.ru *

151.101.84.84 pinterest.com

194.190.168.1 ntp.ix.ru (сервер времени на MSK-IX)

217.20.155.10 odnoklassniki.ru, ok.ru, tamtam.chat

195.128.157.74 mail.dom.gosuslugi.ru, mir24.tv

95.213.222.13, 95.213.222.9 smi2.ru

87.240.129.133 vk.com

213.180.204.90, 77.88.21.90 mc.yandex.ru

 

 

 

Сегодня ночью в реестре Роскомнадзора внезапно появилось пять IP-адресов «Яндекса». Наши адреса пробыли в реестре около двух часов, на текущий момент IP-адреса из этого списка пропали. Дежурная смена наших технических специалистов всю ночь оперативно мониторила ситуацию и поддерживала полную доступность наших сервисов. Мы ждём разъяснений Роскомнадзора.

 

Попытка заблокировать Telegram в России неожиданно стала ударом по всему рунету. Блокировка коснулась не только мессенджера — пострадали многие ресурсы и их пользователи. Мы не считаем эту ситуацию нормальной.

 

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

 

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

Очир Манджиков

директор по связям с общественностью «Яндекса»

 

 

Обсуждение на хабре https://habr.com/post/354484/

там предполагают причину

 

Как такое могло произойти?

 

Во всей этой ситуации примечателен не сам факт блокировки — тут ничего нового, а возможные причины появления именно такого списка заблокированных IP.

 

Давайте представим что вы — РКН, и вам поручили заблокировать Телеграм. Откуда вы, РКН, может взять IP для блокировки Телеграма? Само очевидное решение было бы где-то перехватывать трафик Телеграма, брать оттуда IP, к которым он пытается подсоедениться, и отправлять в блокировку. Для этого достаточно простейшего правила вида iptables -j LOG и скрипта из tail -f, grep и xargs для вызова программы добавления в блок-лист.

 

Перехватывать трафик РКН было бы оптимально с мобильного приложения, так что самым очевидным решением было бы настроить Wi-Fi точку доступа, подключенную через подконтрольный роутер, а к ней подключить телефон, на котором будет открыт Телеграм. Так любые попытки подсоединения к серверам телеграма будут отслеживаться, адреса — блокироваться.

 

Если посмотреть на список заблокированных, то бросается в глаза счётчики и рекламные сети. Такое чувство что кто-то с устройства, предназначенного для блокировки Телеграма, зашел в обычный интернет и пошел по разным сайтам. Скорее всего это было какое-то другое устройство, которое по случаю подключилось к той же Wi-Fi сети. Судя по присутствию сайта whatismyipaddress.com в списке заблокированных, это мог быть даже не сотрудник РКН, а какой-то посторонний человек, по случаю нашедший открытую Wi-Fi сеть или подобравший пароль. Впрочем, бритва Хэнлона подсказывает что от сотрудников РКН можно ожидать и не такого.

 

О чём это говорит?

 

Если раньше владелец заблокированного домена мог добавить в блок-лист произвольные IP адреса заменой A записи, то сейчас ситуация выходит на совершенно новый уровень. Просто представьте себе: что если Телеграм будет пытаться открыть не свои сервера, а просто обратится к IP топовых сайтов? IP объектов инфраструктуры?.. Эти все IP по логике Роскомнадзора быстренько попадут в список под блокировку, а затем также быстро в выгрузку провайдерам.

 

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

 

Из этой возможности естественно следует появление белого списка адресов, которые никогда нельзя заблокировать. Можно предположить такой список уже есть, ведь IP сервера, откуда провайдеры берут новые данные, уже попадал в выгрузку с понятными последствиями, но этому списку явно есть куда расти (сообщают что там было порядка 500 IP). Само наличие такого полного белого списка влечет за собой возможность в какой-то момент отключить всё, кроме белого списка. Это не может радовать.

[Пэтро]

А могли со серьезной миной и оставить эти адреса в списке блокированных, а чо?

[_sv_]

она может быть зашифрована ...

Конечно - ключи не хранятся. Они вообще нигде не хранятся кроме конечных "потребителей".

 

как при таком раскладе шифруются многопользовательские конференции.

В Телеграм? Или принципиально?

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

[_sv_]

мне до конца оставляет открытым вопрос: "Secret Chat key" каким образом доставляется собеседникам, открытым или закрытым?

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

 

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

[_sv_]

Многопользовательские не шифруются

Почему? Решили, что не надо?

[Rumlin]

Почему? Решили, что не надо?

а может следующий шаг после раскрутки популярности, но уже платно.

[KillerSerg]

Почему? Решили, что не надо?

Слишком много архитектурных сложностей:

они считают что число участников в канале может быть неограниченным

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

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

сложней реализовывать самоуничтожение сообщений

итд

В таких условиях e2e труднореализуем

 

Но скорей всего посчитали не нужным концептуально, смысла к секретных чатах на троих нет. По принципу "то что знают трое - знают все"

Одно дело тет-а-тет, с уверенностью что сообщение не перехватили и содержимое знает только два собеседника.

И совсем другое когда чат на троих. Скажем содержимое этого чата утекло. В себе самом есть уверенность. Но кто из двух оставшихся собеседников слил беседу?

[_sv_]

много архитектурных сложностей...

посчитали не нужным концептуально...

Понятно. С фразой "сложности" не соглашусь, но это и не важно.

То, что такое посчитали не нужным - мне понятно. Спасибо.

[KillerSerg]

С фразой "сложности" не соглашусь, но это и не важно.

Предложите вариант реализации?

[_sv_]

Предложите вариант реализации?

какой из проблем?

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

Число участников можно ограничить. Каким-либо разумным числом.

Удаление сообщений по тем же правилам, что и все остальные.

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

Ничего не забыл?

[KillerSerg]

История - не нужна.

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

 

Число участников можно ограничить. Каким-либо разумным числом.

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

 

Удаление сообщений по тем же правилам, что и все остальные.

Удаление сообщений в секретном e2e - по факту прочтения сообщения собеседником. Удаление и у получателя, и у отправителя. В случае многопользовательского чата сложно отображать в интерфейсе кто прочитал сообщение а кто нет, и вообще теряется логика автоудаления.

 

Я уже говорил - один из участников становится ведущим и перешифровывает сообщения в пул.

это вообще очень плохо, слишком много привилегий получается у ведущего. Перешифровывает чем? Своим ключем. Других у него нет. Как вывод - сообщения от ведущего могут быть недостоверными, то есть ведущий может подделать сообщения. Грубо говоря когда в беседе между X, Y и Z ведущим стал Y, то он может перешифровать своим ключем то сообщение, что X писал для Z - то такой чат нам не нужен.

[_sv_]

говорят, что история нужна.

Ну значит пул будет разбрасывать и историю. Подключился и на тебе - чтения на пару часов. В конце-концов на каждом клиенте пул будет одинаков. Любой сможет стать ведущим.

 

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

Хорошо пускай будет неограниченное. Будет тормозить после "разумного числа". Не нравится - покупай лапоть мощнее и плати больше за канал. Делов-то.

 

Удаление сообщений в секретном e2e - по факту прочтения сообщения собеседником. Удаление и у получателя, и у отправителя.

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

Это реальные требования? Удаляться должно с экрана? Глазом повел влево и правая часть начала стираться?

 

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

 

сообщения от ведущего могут быть недостоверными.

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

 

когда в беседе между X, Y и Z ведущим стал Y, то он может перешифровать своим ключем то сообщение, что X писал для Z - то такой чат нам не нужен.

Эп... Мы понимаем друг друга? Если X хочет поговорить с Z, но при этом лезет в чат с Y, то кто же ему доктор? Чего бы не установить прямую беседу между X и Z?

 

Но мне кажется, что мы выходим за рамки темы.

То, что я имел ввиду, когда говорил, что технических проблем нет - я уже объяснил. По крайней мере мне так кажется. Если мы будем выдумывать требования и обсуждать проблемы, то доберемся до реально работающих атак на SSL и другие E2E соединения. После этого окажется, что MINM, от которой отказались пару страниц назад, успешно работает. Как минимум по той причине, что протокол очень безопасен. А вот клиент на противоположной стороне - нет.

Изменено 27 апреля, 2018 пользователем _sv_

[SlavaD]

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

[_sv_]

проще на сервере шифровать, хоть какое-то подобие защиты будет.

Проще - да. Безопаснее - нет.

Изменено 27 апреля, 2018 пользователем _sv_

[KillerSerg]

Ну значит пул будет разбрасывать и историю. Подключился и на тебе - чтения на пару часов. В конце-концов на каждом клиенте пул будет одинаков. Любой сможет стать ведущим.

Пул\Ведущий - не источник достоверной истории. В реализации полного e2e для многопользовательского чата нужна непосредственная передача сообщений от каждого участника чата к каждому. То есть появился новый участник в чате, проанонсил свой паблик кей, ожидает хистори, нотолько отправитель оригинального сообщения может переслать свой кусочек истории чата, содержание только своих сообщений. Нет отправителя в онлайне - нет его сообщений новичку. Это полный end to end. Ваша идея использования ведущего - по сути почти замена клиент-серверной модели. Только там сервер держит копию чата и рассылает его новичкам, а тут это будет делать ведущий. Мы считаем что нет доверия серверу. С чего вдруг должно быть доверие ведущему? И толку от того что ведущим может стать любой?

 

Хорошо пускай будет неограниченное. Будет тормозить после "разумного числа". Не нравится - покупай лапоть мощнее и плати больше за канал. Делов-то.

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

 

Это реальные требования? Удаляться должно с экрана? Глазом повел влево и правая часть начала стираться?

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

На самом деле это конечно игрушка маркетологов, в случае кастомных клиентов это самое удаление можно отключить.

 

Мой посыл таков: нет ничего технически сложного в том, что бы клиент установил кучку шифрованных соединений и умно тиражировал сообщения между ними.

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

 

Эп... Мы понимаем друг друга? Если X хочет поговорить с Z, но при этом лезет в чат с Y, то кто же ему доктор? Чего бы не установить прямую беседу между X и Z?

Об этом изначально же и говорил. Что секретные чаты нужно только один на один. В групповом чате для e2e мало смысла.

А по моему примеру. Чуть расширю пример.

Есть многопользовательский чат, его открывают X и Y, в расчете на то что позже присоединятся еще пользователи. X говорит Y, что скоро должен прийти Z. Ему надо сказать что бы он переводил деньги на счет 1234. И после этого X уходит в оффлайн. Через некоторое время приходит Z и говорит "мне некий X ничего не передавал?". Что мешает "ведущему" X сообщить не исходный номер счета, а свой собственный вместо него? Подпись X под сообщением? Так нет PKI в которой можно проверить что это X. Да, этот вопрос должны были решать между собой X и Z непосредственно, без привлечения Y. Но вот они поверили в мультиюзерский e2e чат. Который в случае "ведущего" в чате себя не оправдал. Это все равно как переводчик в случае допроса иноязычного пленного в ситуации когда никто кроме переводчика не знает этих двух языков.

Было бы совсем по другому, если бы чат создавали X Y Z одновременно, и на стадии создания обменялись своими ключами. Тогда ведущий хранит у себя сообщение от X закриптованое непосредственно ключом Z. Но с ростом числа пользователей в чате брокеру сообщений выпадает слишком большая нагрузка. И это не решает вопрос распространения истории, когда приходит новый пользователь в чат.

 

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

 

 

Но мне кажется, что мы выходим за рамки темы.

Зато прикольно поболтали :)

[KillerSerg]

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

Так это и будет именно та реализация которая есть сейчас. Клиент1-сервер. Сервер хранит всю историю. Сервер-клиент2.

Но есть опасение, что Дуров отдал злополучные ключи в ФБР и ЦРУ :)

ФСБ ведь не нужны были пользовательские ключи от секретных чатов, и они понимали что если те чаты питерских террористов были секретными e2e, то шансов на их расшифровку нет. Им нужны именно серверные сертификаты. А требовали они именно серверные ключи, что бы иметь возможность расшифровывать из данных СОРМа все переписку из групповых и личных не e2e чатов.

[_sv_]

Что секретные чаты нужно только один на один. В групповом чате для e2e мало смысла.

С этим вроде бы никто и не спорил. Или я ошибаюсь?

 

Ведущий - не источник достоверной истории.

Что мешает "ведущему" X сообщить не исходный номер счета, а свой собственный вместо него? Нет PKI в которой можно проверить что это X.

С чего бы это? Конечно источник истории. А вот достоверность её - это атрибут, который необходимо обеспечивать техническими средствами. Отсутствие инфраструктуры это сделать лишь следствие того, что такая задача не ставилась. Но технически тут все исследовано.

 

В реализации полного e2e для многопользовательского чата нужна непосредственная передача сообщений от каждого участника чата к каждому.

Мы считаем что нет доверия серверу. С чего вдруг должно быть доверие ведущему?

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

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

 

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

каждому их учатсников чата надо ее энкриптить и отсылать персонально.

Это увеличивает использование ресурсов в чатах где будет больше десятка участников.

Почему "только"? Как вариант реализации - да. Исключительность - нет.

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

Да и само шифрование AES по скорости сравнимо с чтением из ОЗУ. Это напряжет только очень ленивые устройства.

 

автоудаление через сколько то там секунд,

после появления на экране получателя сообщение считается прочтенный и через это количество секунд удаляется.

Отправителю идет сообщение что получатель прочитал и тоже удаляется.

это самое удаление можно отключить.

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

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

Автоудаление? А как же быть с теми, кто подключится в чат позже? Все должны вспомнить свои сообщения, передать бедняге и потом опять забыть? До следующего подключившегося?

 

Зато прикольно поболтали :)

Надеюсь.

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

[Пакость]

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

А вот можешь объяснить, что есть: "error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure"

И мысли как с этим возможно бороться? Если есть хоть какие-то...

В исполнении CURLа (wget впрочем тоже так-же валится) Но вот в "больших" браузерах разрабы эту тему как-то порешали.

В попытках подключения к некоторым глючным серверам (deviantart.com с последнего времени например)

 

Пир 0: Создан

* Trying 52.84.150.11...

* TCP_NODELAY set

* Connected to deviantart.com (52.84.150.11) port 443 (#0)

* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH

* (303) (OUT), TLS Unknown, Unknown (22):

* (303) (OUT), TLS handshake, Client hello (1):

* (303) (IN), TLS Unknown, Unknown (21):

* (303) (IN), TLS alert, Server hello (2):

* error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure

* Closing connection 0

Curl остановил Пир 0: с кодом 35(SSL connect error)

Пир 0: Остановлен с кодом 0x81000023(SSL connect error)

Загрузка прервана

===========

<<Это с OpenSSL v1.0.2k, с другими версиями - пробовал - абсолютно то-же самое. И учитывая что тот самый deviantart вполне уже начинает шевелиться на Opera 11.52 (вкл. по инфо браузера) сама библиотека "TLS v1.2 128 bit AES (2048 bit RSA/SHA-256)" должна уметь.

 

 

ЗЫ, да, типа сменим пластинку, но в той-же области.