Android SSL No peer certificate – Stack Overflow

Что насчет x509?

PKI{X} и интернет форма пересечение. Что интернет пользователи ожидают и что они получает от CA может различаться очень сильно. Например, интернет пользовать хочет достичь безопасности, пока CA хочет преуспеть в доходах и правовых аспектах. Многие удивлены, когда узнают, что пользовать часто требует применить верификацию идентификацию хоста, даже если CA выпустил сертификат (детали похоронены в CA гарантиях на их сертификаты и их Certification Practice Statement (CPS)).

Есть множество доступных PKI профилей. Для интернета представлет интерес, «Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL)», так же известеный как RFC 5280. С тех пор как сертификат специфицирован в ITU’s X509 стандарте, есть множество обязательных и опциональных полей доступных для проверки для обоих тел. Из-за непересекающихся целей между группами, в следующем разделе содержатся рекомендации.

Что такое pinning?

Pinning — это процесс ассоциации хоста с его ожидаемым  X509 сертификатом или публичным ключом. Если сертификат или публичный ключ известен или виден для хоста, то сертификат или публичных ключ ассоциирован или «связан»(англ. — pinned) с хостом.

Если более чем один сертификат или публичный ключ принимается. то программа содержит pinset(набор сертификатов, взято от Jon Larimer and Kenny Root Google I/O talk) В этом случае, рекламируемая идентичность должна совпадать с одним из элементов набора pinset.

Хост или сервисный сертификат или публичный ключ могут быть добавлены в приложение на этапе разработке или он может быть добавлен во время первой встречи с сертификатом или публичным ключом. Во первых — добавление на этапе разработки — предпочтительнее предзагрузки сертификата или публичного ключа out of band обычно означает, что атакующий не может заразить связь.

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

Так же следует упомянуть, что Pinning это не Stapling. Stapling отправляет и сертификат и информацию о OCSP ответчике в одном запросе, для избежания дополнительных выборок для клиента во время валидации пути.

Есть что еще почитать?

Pinning является хорошо забытой старой вещью, которую подняли, отряхнули и положили в новую упаковку. Пока «pinning» и «pinsets» относительно новые термины, для старых вещей, Jon Larimer и Kenny Root провели некторое время по этой теме на Google I/O 2021 с их беседой на тему Security and Privacy in Android Apps.

Введение

Безопасные каналы связи — это краеугольный камень для пользователей и сотрудников, который работают удаленно или находятся в пути. Пользователи и разработчики ожидают end-to-end безопасности, когда отправляют и получают данные — особенно это касается важных данных при отправке через каналах связи, защищенные VPNом, SSL или TLS.

В то время как организации, которые контролируют DNS и CA(прим. ред.: Certification Authority — удостоверяющие центры, задача которых подтверждать подлинность ключей шифрования с помощью сертификатов) снизили риски до нуля для большинства моделей угроз, пользователи и разработчики, которые находятся под другими DNS и публичным CA в иерархии, подвергаются угрозам, выходящим за рамки обычных моделей.

Пандемия злоупотребления доверием оказала влияние на пользователей, разработчиков и приложения, которые принимают решения по безопасности на непроверенных источниках(англ. — input). Эта ситуация сродни парадоксу: сущности, такие как DNS и CAs  являются доверенными и подразумевается, что они обеспечивают доверенные источники; в то время как их источник не может быть доверенным.

Pinning эффективно устраняет «доверенную среду» между клиентом и сервером. Приложению, которое связано с сертификатом или публичным ключом сервера, уже не требуется зависеть от других — например DNS или CAs — когда принимает решения по установке безопасного соединения, опираясь на идентификацию однорангового участника подключения.

Для тех, кто знаком с SSH, должны понимать, что связывание публичного ключа — почти идентично опции SSH’s StrictHostKeyChecking. Все это время SSH делала всё правильно и остальной мир только начинает понимать достоинства прямой идентификации хоста или сервиса по его публичному ключу.

Есть и другие, кто активно занимается pinning’ом, например Google и его браузер Chrome. Chrome преуспел в обнаружении компрометации DigiNotar, в результате чего раскрылся подозрительный перехват трафика Иранским правительством и его жителями.

Что с чем должно быть связано

Первая вещь, которую надо решить это что с чем должно быть связано. У вас на выбор две вещи: вы можете (1) связать сертификаты; или (2) связать публичные ключи. Если вы выберете публичные ключи, то у вас появиться еще два дополнительных выбора: (а) связать subjectPublicKeyInfo; или (b) связать один из конкретных типов, таких как RSAPublicKey или DSAPublicKey.

Эти три выбора объясняються ниже в деталях. Я бы

«дал вам конфетку»

пооищрил, за то, что вы связали бы 

subjectPublicKeyInfo

, потому что у него есть публичные параметры(такие как 

{e,n} 

для RSA публичного ключа)

и 

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

Android ssl no peer certificate

javax.net.ssl.SSLPeerUnverifiedException: No peer certificate

openssl s_client -connect eu.battle.net:443

Certificate chain
 0 s:/C=US/ST=California/L=Irvine/O=Blizzard Entertainment, Inc./CN=*.battle.net
   i:/C=US/O=Thawte, Inc./CN=Thawte SSL CA
 1 s:/C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2006 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA
   i:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailAddress=premium-server@thawte.com
 2 s:/C=US/O=Thawte, Inc./CN=Thawte SSL CA
   i:/C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2006 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA

Certificate chain
 0 s:/C=US/ST=California/L=Irvine/O=Blizzard Entertainment, Inc./CN=*.battle.net
   i:/C=US/O=Thawte, Inc./CN=Thawte SSL CA
 1 s:/C=US/O=Thawte, Inc./CN=Thawte SSL CA
   i:/C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2006 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA
 2 s:/C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2006 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA
   i:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailAddress=premium-server@thawte.com

Disclaimer

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

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

Essl — embedded secure socket layer

Дальше я представлю на Ваш суд результаты моих исследований данного вопроса проверенные опытным путем. Термин

eSSL

пришел мне в голову в процессе написания этой статьи, так что любые упоминания прошу употреблять вместе со ссылкой на

Итак, освещу немного

важные аспекты строения сертификатов

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

private key

). Сертификат также содержит в себе открытый ключ для проверки подлинности данных содержащихся в этих строковых полях. Перечень полей определен в формате Х.509 v3 и описан в документе

RFC 5280

(это последняя на данный момент редакция документа, до этого действовал

RFC 3280

). Сертификат содержит поле

commomName

которое описывает имя субъекта сертификации, обычно оно совпадает с доменом веб-сайта для которого выпущен сертификат, но в стандарте нет никаких запретов на то что будет вписано в эту строку, например, строка “Вася Пупкин” будет так же валидна для этого поля с точки зрения стандарта — это

первый аспект

. Но веб-браузеры проверяют именно это поле на соответствие с именем сайта который предъявляет сертификат. К счастью для нас в формате X509 v3 определены дополнительные расширения, одно из которых

subjectAltName

, которое позволяет добавить идентификаторы, связанные с основным именем субъекта сертификации (

commomName

). Такими идентификаторами могут быть:

и это

второй

и, пожалуй, наиболее важный

аспект

строения сертификатов 3й версии стандарта. Дело в том что таких идентификаторов можно добавить несколько, т.е. можно вписать несколько IP адресов для которых будет валиден выпущенный сертификат. А это и есть то что нам нужно в случае если некое устройство имеет два Ethernet интерфейса для работы в разных под-сетях, да еще и возможность выхода в сеть через различные типы модемов, если соединение будет по PPP, то это будет третий интерфейс со своим IP адресом. Опытным путем мною был установлен

один важный момент

в назначении альтернативных IP адресов. Браузеры Internet Explorer и FireFox по разному производят проверку альтернативных имен. FireFox сверяет адрес который указан в идентификаторе

IP

, а IE — сверяет адрес с идентификатором

DNS

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

должен быть указан и как IP и как DNS

. О том как это сделать будет рассказано дальше.

No peer certificate available

openssl s_client -connect host:389 -showcerts -state

CONNECTED(00000003)
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
140319263606600:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake f         failure:s23_lib.c:184:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 112 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE

ldapsearch -d -1 -x -LLL -ZZ

No peer certificate available with self signed certificate

// General initialisation
SSL_load_error_strings();
OpenSSL_add_ssl_algorithms();
// Context for a server socket
ctx = SSL_CTX_new(SSLv23_server_method ()); //Note SSLv23_server_method in example is deprecated in favour of TLS_server_method for new versions. TLSv1_2_server_method will force TLS 1.2.
SSL_CTX_set_ecdh_auto(ctx, 1);
SSL_CTX_use_certificate_file(ctx, "cert.pem", SSL_FILETYPE_PEM);
SSL_CTX_use_PrivateKey_file(ctx, "key.pem", SSL_FILETYPE_PEM);
// Only after all certificates, and other config is set
ssl = SSL_new(ctx);
SSL_set_fd(ssl, client_socket);
SSL_accept(ssl);
// Use SSL_write and SSL_read
SSL_free(ssl);
close(client_socket);
// OpenSSL cleanup
EVP_cleanup();

No relationship ^@$!

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

Второе, плохие сертификаты отслеживаються быстро благодоря таким проектам как Chromium и Certificate Patrol, и инициатив EFF’s SSL Observatory.

В третьих, помощь уже в пути. есть множество фьючерсов, которые помогут в вашем стремлении:

Пока Sovereign Keys и Convergence все еще требуеют от нас удостовериться во внешнем источнике, участвующие стороны не служат акционерам и не приносят доходы. Их интересы это прозрачность в индустрии и безопасность пользователей.

Openssl

Pinning может быть достигнуто одним и двух способов в OpenSSL. Первое это пользователь поддерживает verify_callback. Второе это после того, как связь установилась via SSL_get_peer_certificate. Или метод вам разрешит доступ к сертификату peer’а.

Хоть OpenSSL выполняет проверки X509, вы должны разорвать соединение и выключить socket в случае ошибки.  В связи с архитектурой, сервер, который не поддерживает сертификат может вернут результат X509_V_OK с NULL сертификатом. Чтобы проверить результат обычной проверки вам надо: (1)

Download: OpenSSL sample program.

Pinning пробелы

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

Второе — это отзыв сертификата. Клиенты обычно не вовлечены в проверку даты отзыва сертификата, поэтому возможно использовать плохой сертификат или ключ в pinset. Даже если отзыв случился, то доступ к Certificate Revocation Lists (CRLs) и Online Certificate Status Protocol (OCSP) может быть заблокирован во враждебной среде.

Альтернативы pinning’у.

Не все приложения используют split-key криптографию. К счастью, есть протоколы, которые позволяют вам настроить безопасные каналы связи, основываясь на знании паролей и пре-хешированных секретов(лучше чем класть секрет в сеть в базовой схеме аутентификации). Два расположены ниже — SRP и PSK. SRP и PSK имеют 88 шифро наборов назначенных им, так что выбор есть.

Srp

Secure Remote Password (SRP) это Password Authenticated Key Exchange (PAKE) by Thomas Wu основанный на Diffie-Hellman. Протокол стандартизован в RFC 5054 и доступен в OpenSSL библиотеке (среди остальных). В схеме SRP, сервер использует верифаер, который состоит из  следующей пары: {salt, hash(password)}. У пользователя есть пароль, а соль получает от сервера. В каждом инстансе, обе стороны выбирают рандомные значения(одноразовые номера) и выполняют протокол, используя g^{{(salt password)|verifier} nonces} — это лучше чем традиционный Diffie-Hellman g^ab.

Базовые схемы Diffie-Hellman являются частью целого набора проблем в основе Discrete Logs (DL), которые являются логарифмами над конечным полем. DL схемы привлекательные, потому что тяжелые (до тех пор, пока P=NP).

Psk

PSK это Pre-Shared Key и специфицированны в RFC 4279 и RFC 4764. Общий секрет используется в качестве pre-master секрета в TLS-PSK для SSL/TLS; или используется для ключа в блочном шифре EAP-PSK. EAP-PSK спроектирован для аутентификации через небезопасные сети, такие как IEEE 802.11.

Разное

Этот раздел покрывает «бумажную работу» и другие различные вещи связанные с pinning’ом.

Эфемерные ключи

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

Эфемерные ключи не влияют на pinning, потому что он доставляется в другом сообщении —  ServerKeyExchange. В дополнение, эфемерные ключ это ключ, а не сертификат, поэтому он не меняет конструкции из цепочки сертификатов. Вот так, certificate of interest будет все еще располагаться в  certificates[0].

Pinning пробелы

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

Второе — это отзыв сертификата. Клиенты обычно не вовлечены в проверку даты отзыва сертификата, поэтому возможно использовать плохой сертификат или ключ в pinset. Даже если отзыв случился, то доступ к Certificate Revocation Lists (CRLs) и Online Certificate Status Protocol (OCSP) может быть заблокирован во враждебной среде. Приложение может пытаться устранить недостаток, где основным критерием является «актуальность». Вот так, приложение должно обновляться и распространяться немедленно, когда критические параметры безопасности меняются.

No relationship ^@$!

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

Второе, плохие сертификаты отслеживаються быстро благодоря таким проектам как Chromium и Certificate Patrol, и инициатив EFF’s SSL Observatory.

В третьих, помощь уже в пути. есть множество фьючерсов, которые помогут в вашем стремлении:

Про сертификаты:  Срок действия сертификата истек, что делать? Общие сведения о сертификатах безопасности

Пока Sovereign Keys и Convergence все еще требуеют от нас удостовериться во внешнем источнике, участвующие стороны не служат акционерам и не приносят доходы. Их интересы это прозрачность в индустрии и безопасность пользователей.

Есть что еще почитать?

Pinning является хорошо забытой старой вещью, которую подняли, отряхнули и положили в новую упаковку. Пока «pinning» и «pinsets» относительно новые термины, для старых вещей, Jon Larimer и Kenny Root провели некторое время по этой теме на Google I/O 2021 с их беседой на тему Security and Privacy in Android Apps.

Соглашения по формату

В качестве соглашения с читателями, возьмем за пример данную конвертацию между PEM и DER форматами, используя OpenSSL.

# Public key, X509
$ openssl genrsa -out rsa-openssl.pem 3072
$ openssl rsa -in rsa-openssl.pem -pubout -outform DER -out rsa-openssl.der

# Private key, PKCS#8
$ openssl genrsa -out rsa-openssl.pem 3072
$ openssl pkcs8 -nocrypt -in rsa-openssl.pem -inform PEM -topk8 -outform DER -out rsa-openssl.der

Используемые материалы

• OWASP Injection Theory
• OWASP Data Validation
• OWASP Transport Layer Protection Cheat Sheet
• IETF Public Key Pinning
• IETF RFC 5054 (SRP)
• IETF RFC 4764 (EAP-PSK)
• IETF RFC 1421 (PEM Encoding)
• IETF RFC 5280 (Internet X.509, PKIX)
• IETF RFC 4648 (Base16, Base32, and Base64 Encodings)
• IETF RFC 3279 (PKI, X509 Algorithms and CRL Profiles)
• IETF RFC 4055 (PKI, X509 Additional Algorithms and CRL Profiles)
• IETF RFC 2246 (TLS 1.0)
• IETF RFC 4346 (TLS 1.1)
• IETF RFC 5246 (TLS 1.2)
• IETF RFC 6698, Draft (DANE)
• EFF Sovereign Keys
• Thoughtcrime Labs Convergence
• RSA Laboratories PKCS#1, RSA Encryption Standard
• RSA Laboratories PKCS#6, Extended-Certificate Syntax Standard
• ITU Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)
• TOR Project Detecting Certificate Authority Compromises and Web Browser Collusion
• Code Project Cryptographic Interoperability: Keys
• Google I/O Security and Privacy in Android Apps
• Trevor Perrin Transparency, Trust Agility, Pinning (Recent Developments in Server Authentication)
• Dr. Peter Gutmann’s PKI is Broken
• Dr. Matthew Green’s The Internet is Broken
• Dr. Matthew Green’s How do Interception Proxies fail?
• Presentation: SSL Pinning implementation and bypasses for iOS and Android

• Jeffrey Walton — jeffrey, owasp.org
• JohnSteven — john, owasp.org
• Jim Manico — jim, owasp.org
• Kevin Wall — kevin, owasp.org
• Ricardo Iramar — ricardo.iramar, owasp.org

Импорт корневого сертификата в firefox 6(linux)

В FireFox 6 это делается черех меню

Preferences

->

Encryption

->

View Certificates

, выбираем вкладку

Authorities

Далее нажимаем

Import

и открываем файл нашего корневого сертификата

ca.crt

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

И мы можем лицезреть наш сертификат в списке доверенных центров

Импорт корневого сертификата в ie8 (windows 7 64bit)

В меню Пуск в строке поиска наберите certmgr и нажмите комбинацию клавиш Ctrl Shift Enter, ответьте утвердительно на запрос прав администратора. У Вас запустится менеджер сертификатов.

Дважды кликните на разделе Trusted Root Certification Authorities

Кликните правой кнопкой мыши на Certificates -> All Tasks -> Import…

Запустится мастер импорта сертификатов, следуйте его инструкциям и в качестве сертификата укажите ca.crt. Если в результате получите ошибку

То поправьте ключ в реестре

HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftSystemCertificatesRootProtectedRootsFlags

установите его в

0

и перезапустите менеджер сертификатов.

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

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

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

Используемые материалы

• OWASP Injection Theory
• OWASP Data Validation
• OWASP Transport Layer Protection Cheat Sheet
• IETF Public Key Pinning
• IETF RFC 5054 (SRP)
• IETF RFC 4764 (EAP-PSK)
• IETF RFC 1421 (PEM Encoding)
• IETF RFC 5280 (Internet X.509, PKIX)
• IETF RFC 4648 (Base16, Base32, and Base64 Encodings)
• IETF RFC 3279 (PKI, X509 Algorithms and CRL Profiles)
• IETF RFC 4055 (PKI, X509 Additional Algorithms and CRL Profiles)
• IETF RFC 2246 (TLS 1.0)
• IETF RFC 4346 (TLS 1.1)
• IETF RFC 5246 (TLS 1.2)
• IETF RFC 6698, Draft (DANE)
• EFF Sovereign Keys
• Thoughtcrime Labs Convergence
• RSA Laboratories PKCS#1, RSA Encryption Standard
• RSA Laboratories PKCS#6, Extended-Certificate Syntax Standard
• ITU Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)
• TOR Project Detecting Certificate Authority Compromises and Web Browser Collusion
• Code Project Cryptographic Interoperability: Keys
• Google I/O Security and Privacy in Android Apps
• Trevor Perrin Transparency, Trust Agility, Pinning (Recent Developments in Server Authentication)
• Dr. Peter Gutmann’s PKI is Broken
• Dr. Matthew Green’s The Internet is Broken
• Dr. Matthew Green’s How do Interception Proxies fail?
• Presentation: SSL Pinning implementation and bypasses for iOS and Android

• Jeffrey Walton — jeffrey, owasp.org
• JohnSteven — john, owasp.org
• Jim Manico — jim, owasp.org
• Kevin Wall — kevin, owasp.org
• Ricardo Iramar — ricardo.iramar, owasp.org

Как всё это применять?

Итак, мы создали 2 вида сертификатов, корневой сертификат и сертификат пользователя. Корневой сертификат, как правило, создается один раз и в дальнейшем используется для подписи пользовательских сертификатов, которые мы раздаем пользователям, т.е. помещаем на наши девайсы. Разберемся, как их применять.

Сертификат пользователя и ключ к нему нужно поместить на целевое устройство, у меня это некая плата с ARM контроллером и Linux-ом на борту. Не буду описывать этот процесс, т.к. он зависит от WEBсервера, что у нас там установлен.

Как вы pin’ите?

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

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

Когда вводить белые списки?

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

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

Заметка: Если вы добавили в белый список сертификат или публичный ключ для другого хоста (например, перехватывающего прокси) вы более не связываете ожидаемые сертификаты и ключи для хоста. Безопасность и целостность канала связи может пострадать и это естественно ломает end-to-end безопасность пользователя и организации.

Для большей информации о перехатывающих прокси, дополнительный риск, который они дают и как они «лажают» читайте  Dr. Matthew Green’s How do Interception Proxies fail? и Jeff Jarmoc’s BlackHat talk SSL/TLS Interception Proxies and Transitive Trust.

Когда надо pin’ить?

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

Идеальный случай для примера: во время двух недель или около того во время приготовления презентации и шпаргалки мы наблюдали три соответствующие и связанные неудачи. Первая была — Nokia/Opera умышленно сломали безопасный канал связи. Вторая была DigiCert выдала сертификат для подписи зловреда;

Кодировки/форматы

Для целей этой статьи,  объекты в x509 — совместимым формате представления (PKCS#1 откладывает X509, оба используют ASN.1) Если у вас есть PEM закодированный объект (например, —–BEGIN CERTIFICATE—–, —–END CERTIFICATE—–), то конверитруйте объект в DER. Преобработвания используя OpenSLL предложены ниже в разеделе (Соглашения о форматах)

Сертификат — это объект, который связывает сущность(такую как человек или организация) к публичному ключу по средствам подписи. Сертификат закодирован в DER и имеет связь с датой или атрибутами такими как Subject (кто идентифицирован или связан)

Сертификат имеет subjectPublicKeyInfo. SubjectPublicKeyInfo это ключ с дополнительной информацией. Тип ASN.1 включает Algorithm ID, a Version и расширяемый формат для содержания конкретного публичного ключа. Картинка 1 и 2 ниже показывает разные изображения одного RSA ключа, который subjectPublicKeyInfo. Ключ для сайта random.org и используется в примерах программ и в коде ниже.

Конкретный публичный ключ является закодированным публичным ключом. Формат ключа обычно будет указан где-то еще, например PKCS#1 в случае RSA публичных ключей. В этом случае тип RSAPublicKey и параметры {e,n} будут ASN&1 закодированы.

Лекарство

Есть три лекарства для проблемы распространения ключей. Первая — иметь первичное знание о вашем партнере или собеседнике(т.е. сервере или сервисе). Это может быть решено с помощью SneakerNet. К сожалению, SneakerNet не масштабируется и не может быть использовано для решения проблемы распространения ключей.

Второе — довериться другим и это имеет два варианта: (1) web of trust и (2) hierarchy of trust.  Web of Trust и Hierarchy of Trust решают проблему распространения ключей в стерильной среде. Однако,  Web of Trust и Hierarchy of Trust каждый требует от нас, чтобы мы полагались на других — или находились в «доверенной среде»(англ. confer trust). На практике, доверится другим будет проблематично.

Немого общей имформации об ssl

Технология SSL позволяет шифровать трафик между двумя устройствами. Вы, наверное знаете, что SSL сертификаты выдаются web-сайтам и приязываются на домены или поддомены. Сертификаты выдаются доверенными центрами сертификации (

Certification Authority

) и подписываются электронными подписями. Сертификаты подтверждаются в браузерах путем проверки цепочки сертификатов (

Certification Path

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

Проблема

встраиваемых систем

в том, что,

• во-первых, это не web-сайт в общем понимании этого слова (вспомните, например, веб-интерфейс Wi-Fi роутера), в момент выпуска изделия он не имеет окончательного IP адреса, и еще менее вероятно чтобы он имел какой то домен.
• во-вторых, конечный пользователь может сменить и IP, и домен, если таковой был, хотя бы в целях все той же безопастности.
• в-третьих, покупать сертификат довольно дорого, а вопрос снижения себестоимости стоит всегда.

Как же решать эти проблемы?

Нулевой пациент

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

Обязательные проверки

Все проверки X509 должны включать:

• Проверку пути. Проверка верифицирует все подписи всех сертификатов в цепочке тому, что соответствуют выданному PKI. Проверка начинается на сервере или сервисном сертификате(с листка) и протекает назад к доверенному корневому сертификату(к корню).

• Валидация полей notBefore и notAfter. Поле notAfter в особенности важно с тех пор, как CA не будет поддерживать сертификат после этой даты и не должна обеспечивать CRL/OCSP обновления после этой даты.

Пару слов про owasp

Это перевод статьи международной организации The OWASP (Open Web Application Security Project) — Certificate and Public Key Pinning. Данная организация занимается проектом обеспечения безопасности веб приложений.

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

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

OWASP сформировал набор рекомендаций для построения безопасных REST/SOAP сервисов. Разработали стандарт для проведения проверок уровня безопасности приложений. Практически все разработчики мобильных банков стараются следовать их рекомендациям.

Примеры связывания

Эта секция демонстрирует связывание сертификатов и публичных ключей в Android Java, iOS, .Net, и OpenSSL. Все программы пытаютсья соединить random.org и запрашиваемые данные(Dr. Mads Haahr участвует в AOSP’s pinning program, то сайт должен иметь статический ключ)

Параметр проверки возвращает значение проверки, проверка ошибок была опущена в коде ниже, но присутствует в примерах программ. Поэтому пример кода может быть использован для копи/пасты. Забегая вперед, наиболее дискомфортные языки — это С-шные: iOS и OpenSSL.

Проверки публичного ключа

Смотри также (q.v.). Верификация идентичности хоста со знанием об его ожидаемом/связанном публичном ключом.

Публичный ключ

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

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

Разное

Этот раздел покрывает «бумажную работу» и другие различные вещи связанные с pinning’ом.

Сертификат

Легче всего связать сертификат. Вы можете выбрать сертификат из хранлища для вебсайта, можете написать email ИТшникам вашей компании, чтобы они выдали вам сертфикат, использовать openssl s_client чтобы заполучить сертификат и т.д. Когда ваш сертификат подойдет к концу срока действия, то вы просто обновляете приложение. Подразумевается, что если приложение не имеет багов или изьянов в безопасности, то приложение будет обновляться каждый год или два .

Во время исполнения, вы извлекаете сертификат вебсайта или сервера в callback’e. Вместе с callback’ом вы сравниваете извлеченный сертификат с сертификатом вшитым в программу. Если сравнение неудачное, то отклоняете соединение в методе или функции.

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

Сертификаты для устройств

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

Соглашения по формату

В качестве соглашения с читателями, возьмем за пример данную конвертацию между PEM и DER форматами, используя OpenSSL.

# Public key, X509
$ openssl genrsa -out rsa-openssl.pem 3072
$ openssl rsa -in rsa-openssl.pem -pubout -outform DER -out rsa-openssl.der

# Private key, PKCS#8
$ openssl genrsa -out rsa-openssl.pem 3072
$ openssl pkcs8 -nocrypt -in rsa-openssl.pem -inform PEM -topk8 -outform DER -out rsa-openssl.der

Сценарий использования ssl во встраиваемых системах

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

1. Нам потребуется создать самоподписанный корневой сертификат, в этом случае мы станем сами себе центром сертификации.
2. Далее нам нужно создать сертификат для нашего web-интерфейса и подписать его корневым сертификатом, созданным на первом шаге.
3. Этот сертификат мы помещаем в память  нашей встраиваемой системы где его сможет найти встроенный веб-сервер.
4. Всем пользователям веб-интерфейса мы должны выдать наш корневой сертификат, но не приватный ключ.
5. Пользователи веб-интерфейса должны импортировать наш корневой сертификат в свои веб-браузеры на всех компьютерах с которых предполагается вход на веб-интерфейс.

Особо отмечу

, что этот сценарий

не является безопасным

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

Так в чем проблема то?

Пользователи, разработчики и приложения ожидают end-to-end безопасности на их безопасных каналах связи, но некоторые безопасные каналы, таковыми не являются. В частности, каналы связи построенные на всем известных протоколах, таких как  VPN, SSL и TLS могут быть уязвимы к определенному числу атак.

Хеширование

Пока три выбора выше использовали DER кодировки, но еще допустимо использовать hash информацию (или другие производные). На самом деле исходные сэмплы программ были написаны используя переваренные сертификаты и публичные ключи. Сэмплы были изменены, чтобы разрешить программисту исследовать объекты в с помощью таких инструментов , как dumpasn1 и ASN.1 декодером.

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

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

Наконец, третье, организация может захотеть поддерживать резервный(или на случай бекапа) идентичность в случае, если первая идентичность была скомпрометирована. Хеширование удостоверяется ваши противники не увидят резервный сертификат или публичный ключ, чтобы его использовать. На самом деле Google IETF черновик  websec-key-pinning использует данную технику.

Эфемерные ключи

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

Эфемерные ключи не влияют на pinning, потому что он доставляется в другом сообщении —  ServerKeyExchange. В дополнение, эфемерные ключ это ключ, а не сертификат, поэтому он не меняет конструкции из цепочки сертификатов. Вот так, certificate of interest будет все еще располагаться в  certificates[0].