Андроид https не работает

Подводные камни HTTPS в Android

Проснувшись прекрасным праздничным посленовогодним утром (в два часа дня) я привычным движением подобрал планшет и тыкнул пальцем в мою разработку чтоб посмотреть на картинку Солнца.

Не сказать что я был удивлен, когда вместо диска обнаружилась пустота, все таки данные берутся с https://sdo.gsfc.nasa.gov/ и уже бывало что он был не доступен целиком или в части фотографий. Однако увы в браузере все грузилось и было на месте, более того даже на своем месте, т.е. это не смена url.

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

Зацепки

Первое что бросилось в глаза — сайт перешел с http на https.

Второй сюрприз, в версиях android 4.4.2 и выше все работало как надо. Т.е. мне еще повезло что планшет у меня работает на 4.2.

Ну и третье, единственная ошибка в логах: ”Server closed connection”

Рытье

После этого конечно возникло ощущение что какая то беда в протоколах, был нарыт сайт:

SSL Server Test (Powered by Qualys SSL Labs)

A comprehensive free SSL test for your public web servers.

который собственно помог, его основная функция тестирование ssl сайтов, применительно к нашему подопечному https://www.ssllabs.com/ssltest/analyze.html?d=sdo.gsfc.nasa.gov выяснилось что он поддерживает только два протокола: TLS 1.1 и TLS 1.2, что в общем то правильно так как SSL2–3 признаны устаревшими.

И что самое приятное в результатах теста есть часть: “Hadshake Simulation” где сразу видно что сайт нормально работает только с Android 4.4.2 и выше, а так же видна причина, древние версии андроида не работают с протоколами TLS1.1 и 1.2. Затем выяснилось что начиная с android API16 (4.1) данные протоколы встроены, но отключены по умолчанию. И тут мне повезло так как минимальная поддерживаемая версия android моего приложения как раз 4.1.

Решение

Включаем TLS1.1 и TLS1.2

Моя программа стильна модна молодежна 😀 Т.е. написана на kotlin и использует всякие Dagger2, rxJava, Realm, Retrofit2 и т.п. (при этом кстати весит меньше 8Мб)

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

Путем гугления https://github.com/square/okhttp/issues/2372 было найдено готовое решение которое на kotlin выглядит следующим образом:

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

Так как в котлине возможны экстеншены к классам то можно создать такую симпатичную функцию к OkHttpClient.Bilder’у:

Соответственно в коде включение tls выглядит как будто эта функция имеется в самом классе, примерно так:

В этом один из плюсов kotlin, но это уже другая тема.

После этого все заработало как надо.

PS: Небольшая правда уже не сильно полезная ссылка, подробно показывающая какие протоколы в каких версиях андроида используются

Источник

Находки программиста

Решения конкретных задач программирования. Java, Android, JavaScript, Flex и прочее. Настройка софта под Linux, методики разработки и просто размышления.

среда, 27 мая 2015 г.

Https в Android: делаем правильно

To что я опишу ниже — не открытие и не тайна. Это есть даже в официальной документации. Проблема в том, что большинство программистов под Android (и я в том числе) пришли из других, более старых платформ, где проблемы с ssl решались иначе или не возникали вообще.
Например, если сертификат вашего сервера почему-то не в порядке (например он самоподписной), то решение отключить проверку сертификата напрашивается само собой. Такое себе «быстрое решение». В результате вроде бы https и все круто, но на публичном wifi ваш клиент рискует пообщаться по «защищенному» каналу с мошенником. Или, к примеру, вы подключаетесь по ip к своему серверу, а в сертификате прописан домен. Отключаем проверку домена? Давайте не будем спешить. Есть решение которое в «особых» случаях не только не снижает безопасность соединения вашего приложения с сервером но и повышает её до воистину параноидального уровня.

Совсем чуть-чуть теории.

Когда мы устанавливаем https-соединение с сервером, происходит такое себе «рукопожатие», в процессе которого клиент получает публичный ключ сервера. Этот ключ используется для шифрования трафика и для проверки подлинности сервера. Как убедиться что сервер действительно тот, за кого себя выдает? Сертификат, который он предоставляет клиентскому приложению должен быть заверен организацией, чей сертификат есть в системе Android как доверенный и в нём должно быть «зашито» имя домена, соответствующее тому, к которому мы обращаемся. Если мы отключаем проверку, то любой сертификат любого мошенника становится валидным, и вы отправляете ему данные. Он же может общаться с вами, проксируя ваши данные на ваш сервер, который ни о чем не подозревая, обслуживает его как нормального клиента.
Если у вас нет заверенного сертификата, вы можете сгенерировать его себе самостоятельно. Это бесплатно. Но после этого ваше приложение должно доверять этому сертификату «без опоры на авторитеты». Это можно сделать двумя способами: быстрым и правильным. Быстрый — отключить проверку. Правильный: «вшить» публичный ключ вашего сервера в клиентское приложение. Так вы сможете доверять соединению с вашим сервером, не доверяя больше никому, даже самым «супернадежным» сертификатам.

И практика.

Допустим, наш сервер telebank.ru. Он https, причем его сертификат заверен GeoTrust, поэтому мы все ему доверяем. Но допустим, мы хотим принимать его не потому что он заверен кем-то а потому, что он «вшит» в наше приложение. Тогда даже конец света не помешает нам установить защищенное соединение 😉

1. Получим свой публичный ключ:

Из того, что приехало в ответ берём строчки начиная с —BEGIN CERTIFICATE— и заканчивая —END CERTIFICATE—, и сохраняем их в файл, к примеру в telebank.ru.cer. Это и будет наш публичный ключ в base64 представлении.

2. Чтобы работать с ключом, сделаем ему хранилище с помощью BouncyCastle Provider. Скачать его можно, например тут. Скачиваем библиотеку, кладём её рядом с нашим файлом сертификата и выполняем:

И, собственно, наш класс, расширяющий стандартный DefaultHttpClient:

7 комментариев:

Конгениальное решение! Особенно когда завтра у сертификата telebank.ru кончится срок или его перевыпустят по любой другой причине — ваше супергениальное решение немедленно перестанет работать. И пока вас не задолбают благодарные пользователи и вы не перевошьёте другой сертификат — не начнёт. С совершенно валидным сетификатом, подписанным доверенной организацией.

Ваша задача решается куда проще — вы смотрите, доверен ли сертификат и на какой домен он выдан. И неваши домены игнорите. Так вы и используете механизмы подписанных (доверенных) сертификатов, и не разрешаете своему 😉 приложению ходить налево.

Внимательно читая пост, можно заметить что решение предлагается как раз для «особых» случаев, когда сертификат нельзя или нет резона использовать традиционным способом.
Например, ваш сервер используется только как точка доступа для запросов мобильного клиента и не обслуживает браузер в принципе. Зачем покупать для него «совершенно валидный сетификат, подписанный доверенной организацией»?
На счет замены сертификата — этот минус описан, но по-моему замена сертификата раз в несколько лет не должна быть проблемой для мобильного приложения, которое штатно обновляется раз в 2-3 недели.
Ваше решение с проверкой домена — хорошее, но это решение другой задачи. Не пускать приложение «налево» в рамках описанного в посте метода скорее бонус, чем главная цель.

Источник

Туториал: HTTPs запросы с iOS и Android девайсов не расшифровываются в Fiddler

При работе с Fiddler часто возникают проблемы, которые решаются перезапуском сниффера, перезагрузкой компьютера или девайса, с которого сниффится трафик. Но бывает и такое, что перезапуском проблема не решилась и даже полной переустановкой фиддлера. Это статья не о чем-то новом и неизведанном, а скорее туториал, который поможет вам, когда вы всё сделали правильно, но «ничего не работает».

Для начала стоит проверить (даже, если уже проверяли) настройки Fiddler и девайса, с которого вы хотите сниффить трафик.

Настройка Fiddler на Windows для сниффинга трафика с iOS и Android девайсов

Перейти Tools -> Options

Во вкладке Connections установить галочку Allow remote computers to connect

Вкладка Connections

Перезагрузить Fiddler, чтобы изменения вступили в силу

Во вкладке HTTPS:

1) установить галочку на Capture HTTPS CONNECTs

2) установить галочку на Decrypt HTTPS traffic

3) в появившемся окне “Trust the Fiddler Root certificate” кликнуть Yes

4) в окне Security Warning кликнуть Yes

5) в окне Add certificate to the Machine Root List? Нажать Yes

6) в появившемся окне “Do you want to allow this app to make changes to your device?” выбрать Yes

7) установить галочку Ignore server certificate errors (unsafe)

Вкладка HTTPs

В остальных вкладках оставить всё по дефолту, нажать ОК

В верхнем тулбаре активировать Stream и Decode

Настройка iOS девайса для работы с Fiddler

Тапнуть пункт Wi-Fi

Тапнуть иконку i у сети, у которой подключен девайс

Проскроллить вниз и перейти в пункт Configure Proxy

В поле Server ввести свой IP адрес

В поле Port ввести свой Порт, тапнуть Save

Открыть браузер и ввести в адресную строку http://ipv4.fiddler:. Например, если порт 8888, то ссылка будет выглядеть так http://ipv4.fiddler:8888 ИЛИ ввести в адресную строку :, например, 192.168.162.202:8888

Тапнуть на ссылку “FiddlerRoot certificate” и загрузить сертификат

Перейти в Settings -> General -> Profile и установить скачанный сертификат

Перейти в Settings -> General -> About -> Certificate Trust Settings и поставить чекбокс у нашего сертификата

Настройка Android девайса для работы с Fiddler

Тапнуть и удерживать сеть Wi-Fi, к которой подключен девайс

Выбрать Modify Network

Выбрать “Show advanced options”

Тапнуть Proxy и выбрать Manual

В поле Server ввести свой IP адрес

В поле Port ввести свой Порт, тапнуть Save

Открыть браузер и ввести в адресную строку http://ipv4.fiddler:. Например, если порт 8888, то ссылка будет выглядеть так http://ipv4.fiddler:8888 ИЛИ ввести в адресную строку :, например, 192.168.162.202:8888

Тапнуть на ссылку “FiddlerRoot certificate”, сертификат загрузится на девайс

Установка должна произойти автоматически, если сертификат не установился, то свайпнуть вниз и тапнуть иконку Settings

Перейти Personal -> Security

Перейти в Credential Storage и тапнуть “Install from storage”

Тапнуть файл FiddlerRoot.cer

(Опционально) Ввести имя сертификата, например, FiddlerRoot

Проверить эту конфигурацию можно Trusted credentials -> User, там должен отобразится установленный сертификат

Запросы HTTPs остаются зашифрованными

Нужно здесь скачать плагин генерации сертификатов “CertMaker for iOS and Android”

Перейти в Fiddler в Tools -> Options -> HTTPS и в Certificates generated by выбрать CertMarker

На девайс повторно скачать сертификат с http://ipv4.fiddler:, т.к. он будет генерироваться заново

Выполнить установку сертификата на девайсе

После всех вышеописанных манипуляций Fiddler будет послушно декодировать необходимые HTTPs запросы с девайса.

Источник

Старые телефоны Android не смогут открывать множество сайтов

Владельцы множества телефонов Android системы со следующего года не будут иметь доступ ко многим защищенным веб-сайтам с протоколом «https», а это и Вконтакте, и Одноклассники, а также многие другие.

То есть современные и лучше защищенные сайты, которые вы можете узнать по значку замка рядом с адресной строкой. Речь идет о мобильных телефонах и планшетах с Android версии 7.1 и старше (6/5), которые сейчас составляют около трети «андроидного» мира. Для них в сентябре 2021 года истечет срок действия сертификата, которым должны обладать устройства для открытия ряда упомянутых сайтов. А именно, это сертификат «ISRG Root X1» из международного проекта «Let’s Encrypt», который с 2015 года показывает, что сайт официальный и безопасный. Спустя пять лет владельцы старых смартфонов, в том числе на базе Android 7.1 (и более ранние версии) больше не будут поддерживать сайты https.

Так что же теперь делать пользователям?

Есть несколько решений. Самое дорогое — купить смартфон или планшет с более новым Android. Как вариант, вы можете попробовать установить более новую версию «андроид» на свой телефон, но это дело не из легких. Но самый простой способ, рекомендованный разработчиками «Let’s Encrypt» — это использовать браузер Firefox (ни в коем случае не реклама — совет). Он содержит важные сертификаты непосредственно в самой программе и может заменить или дополнить те, которые отсутствуют в устройстве. Проще говоря, в Android 7.1 или более ранней версии с сентября 2021 года вы не будете открывать защищенный веб-сайт из Chrome или основного браузера, а делать это сможете через Firefox.

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

Друзья, а у вас есть такое устройство? Как вы к этому относитесь? Пишите в комментариях. Не забудьте подписаться на канал, а также поставьте, пожалуйста лайк, так вы оцените мою работу.

Источник

Почему на андроиде под нормальные браузеры нет https everywhere

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

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

Перемещено beastie из general

Firefox самый нормальный браузер

Но не на Android.

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

Что тебе мешает самому использовать https-версии сайтов?

Лоллировал. Поумерь своё красноглазие.

Потому что на андроиде (да и мобилках вообще) нет нормальных браузеров.

Оно так просто не работает.

Что просто так не работает? Https? Попустись

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

Источник