При обслуживании содержимого изображения по https сила шифрования должна соответствовать силе основного веб-сайта?
This seems as though it could be browser-dependent, but in my experience, the browsers just require that replaced content in the page be loaded by HTTPS. They don't care what strength it is.
Короче говоря, ваше правильное предположение о том, что любой внешний ресурс, размещенный на сайте https:// с любым типом SSL/TSL и т.д., не будет иметь заметного эффекта для любого из ваших посетителей.
У нас был точно такой же вопрос, когда мы были вынуждены включить некоторые удаленные JS процессором нашей платежной карты.
После некоторых исследований с каждым устройством и комбинацией браузера мы могли получить (и с помощью некоторых веб-инструментов, таких как browsershots.org и modern.ie .
Мы обнаружили, что все браузеры, которые мы тестировали, только предлагали URL загруженной страницы (и это заголовки) при предоставлении клиенту/посетителю висячего/безопасного логотипа соединения.
Очень часто при включении внешних JS/изображений/виджетов и т.д., для включенного внешнего ресурса/файла используются совершенно разные цепочки шифров для TLS/ SSL переговоров.
Даже эксперты записывают наши собственные PCI стандарты ежедневно сканера и отраслевые экспертные ресурсы, которые мы нашли, например www.ssllabs.com, дают обзор и оценку возможностей ваших серверов по ведению переговоров по TLS/SSL/SPDY и т.д., они даже не загружают содержимое документа, не говоря уже о том, что ищут любые включенные внешние ресурсы. Они просто рассматривают вашу способность к рукопожатию на уровне сервера.
В нашем специальном вебсайте /пример, обеспечивающий поддержку последних версий TLS вместе с новым протоколом SPDY от googles, мы получили 'A+' от ssllabs.com и всех браузеров, показывающих защищенный логотип, несмотря на то, что страница включала внешний ресурс javascript, который позволял использовать как устаревшее SSL3, так и 64-битное SSL, но при этом не являющееся новым стандартом шифрования в отрасли.
.