И вновь про фильтрацию HTTPS трафика
Собственно, я писал только про изучение, но никогда не писал - нафига я этим занимаюсь. Исправлюсь :)
У меня есть некоторое количество клиентских устройств у которых медленный или помегабайтный интернет. И есть некоторое количество дешевых серверов с быстрым и безлимитным интернетом, которые можно использовать для обеспечения клиентов улучшенным трафиком. Чтоб был без рекламы, с пожатыми картинками и сжатый в gzip. Когда-то давно, когда HTTPS был только у крупных банков, я для этой цели использовал Ziproxy+BFilter. Но потом начался сначала безлимитный интернет и стало как-то пофиг. Но еще позже у меня появился смартфон, а родители заселились в поселок где исключительно есть только тормозной и часто вылетающий (зато безлимитный!) DSL и помегабайтные ОПСОСы. Вот я и решил на досуге снова поизучать тему.
Первая пришедшая мне в голову мысль - " нахрен HTTPS". Ну, то есть, между клиентом и сервером - да, пусть будет, а вот внутри цепочек прокси он нафиг не сдался. Оказалось, что подобное решение воспринимается как нечто из разряда "выстрелить себе в ногу" и натыкается на некоторые непреодолимые сложности. Для этого:
1. Браузер должен явно посылать http-запросы. При использовании BURP Proxу надо всегда вводить http в адресной строке, иначе будет согласован https
2. Браузер не должен быть Chrome-based, ибо у него вкомпилирован целый лист сайтов с HSTS.
3. И, самый большой недостаток - сервер должен всегда уметь отдавать HTTPS, поскольку нет способа отделять "истинный" http от "преобразованного" https, в результате Burp Proxy всегда должен подсоединяться к 443 порту. Если он недоступен - ой. Как выяснилось, сайтов без HTTPS еще достаточно много.
Так что от такого решения пришлось отказаться. Я начал искать альтернативные варианты, и достаточно быстро натолкнулся на "Proxomitron SSL Helper". Суть полностью показывается на первой же картинке. Технически, эта штука - mitm-proxу, но не монолитная, а "разделенная" на две части - "дешифрующую" и "шифрующую". Весь HTTPS трафик между ними идет расшифрованным, что позволяет "врезать" туда Privoxy и Ziproxy.
В отличие от предыдущего способа, этот способ подходит для любых браузеров, даже для мобильных (хотя, возможно, придется повозиться с proxy.pac).
Недостатки, впрочем, тоже есть.
Первый заключается в том, что обрабатывать "помеченный" трафик умеют только Proxomitron и Privoxy. Однако остальные все-таки использовать можно, но тогда придется городить две цепочки прокси, одна для "чистого"-HTTP трафика, и одна для "меченного". Так что Ziproxy придется запускать в двух экземплярах (не особая проблема).
Второй - в том что тулза написана на python. Но для одного-трех человек ее производительности точно хватит, а более лично мне и не надо.
Интересная идея у меня возникла по поводу сжатия изображений. Ziproxy умеет либо сжимать стандартные типы (png\gif\jpg) с потерей качества, или же преобразовывать их в Jpeg2000. Однако, с тех пор Jpeg2000 так ничем кроме Safari поддерживаться и не начал, но сейчас есть формат webp, который меньше по размеру, имеет меньше артефактов, нативно отрисовывается всеми Chrome-based браузерами, на Android а еще - браузером Pale Moon (впрочем, этот форк Firefox поддерживает даже JPEG XR и BPG).
Теоретически, вместо Ziproxy можно попробовать заюзать, RabbIT, который для преобразования изображений использует ImageMagick. Немножко медленнее, но экономия мобильного трафика должна быть значительно выше.
Еще была идея попробовать использовать HTTP/2, но, как оказалось, nghttpx не рассчитан на использование в качестве прямого прокси.
У меня есть некоторое количество клиентских устройств у которых медленный или помегабайтный интернет. И есть некоторое количество дешевых серверов с быстрым и безлимитным интернетом, которые можно использовать для обеспечения клиентов улучшенным трафиком. Чтоб был без рекламы, с пожатыми картинками и сжатый в gzip. Когда-то давно, когда HTTPS был только у крупных банков, я для этой цели использовал Ziproxy+BFilter. Но потом начался сначала безлимитный интернет и стало как-то пофиг. Но еще позже у меня появился смартфон, а родители заселились в поселок где исключительно есть только тормозной и часто вылетающий (зато безлимитный!) DSL и помегабайтные ОПСОСы. Вот я и решил на досуге снова поизучать тему.
Первая пришедшая мне в голову мысль - " нахрен HTTPS". Ну, то есть, между клиентом и сервером - да, пусть будет, а вот внутри цепочек прокси он нафиг не сдался. Оказалось, что подобное решение воспринимается как нечто из разряда "выстрелить себе в ногу" и натыкается на некоторые непреодолимые сложности. Для этого:
1. Браузер должен явно посылать http-запросы. При использовании BURP Proxу надо всегда вводить http в адресной строке, иначе будет согласован https
2. Браузер не должен быть Chrome-based, ибо у него вкомпилирован целый лист сайтов с HSTS.
3. И, самый большой недостаток - сервер должен всегда уметь отдавать HTTPS, поскольку нет способа отделять "истинный" http от "преобразованного" https, в результате Burp Proxy всегда должен подсоединяться к 443 порту. Если он недоступен - ой. Как выяснилось, сайтов без HTTPS еще достаточно много.
Так что от такого решения пришлось отказаться. Я начал искать альтернативные варианты, и достаточно быстро натолкнулся на "Proxomitron SSL Helper". Суть полностью показывается на первой же картинке. Технически, эта штука - mitm-proxу, но не монолитная, а "разделенная" на две части - "дешифрующую" и "шифрующую". Весь HTTPS трафик между ними идет расшифрованным, что позволяет "врезать" туда Privoxy и Ziproxy.
В отличие от предыдущего способа, этот способ подходит для любых браузеров, даже для мобильных (хотя, возможно, придется повозиться с proxy.pac).
Недостатки, впрочем, тоже есть.
Первый заключается в том, что обрабатывать "помеченный" трафик умеют только Proxomitron и Privoxy. Однако остальные все-таки использовать можно, но тогда придется городить две цепочки прокси, одна для "чистого"-HTTP трафика, и одна для "меченного". Так что Ziproxy придется запускать в двух экземплярах (не особая проблема).
Второй - в том что тулза написана на python. Но для одного-трех человек ее производительности точно хватит, а более лично мне и не надо.
Интересная идея у меня возникла по поводу сжатия изображений. Ziproxy умеет либо сжимать стандартные типы (png\gif\jpg) с потерей качества, или же преобразовывать их в Jpeg2000. Однако, с тех пор Jpeg2000 так ничем кроме Safari поддерживаться и не начал, но сейчас есть формат webp, который меньше по размеру, имеет меньше артефактов, нативно отрисовывается всеми Chrome-based браузерами, на Android а еще - браузером Pale Moon (впрочем, этот форк Firefox поддерживает даже JPEG XR и BPG).
Теоретически, вместо Ziproxy можно попробовать заюзать, RabbIT, который для преобразования изображений использует ImageMagick. Немножко медленнее, но экономия мобильного трафика должна быть значительно выше.
Еще была идея попробовать использовать HTTP/2, но, как оказалось, nghttpx не рассчитан на использование в качестве прямого прокси.