Комментарии 13
Возможно, тут у вас появится вопрос о причинах изменения номера порта сервера на 8443
У меня скорее вопрос, какова вероятность, что HTTPS-запрос к такому серверу зарубит файрвол?
В linux порты меньше 1024 специальные, и обычный пользователь не может слушать на них. Поэтому тут порты больше 1024 — менше технической возни.
Плюс, исторически сложилось что порты 80 и 443 для апача/нжинкса, а все остальные, включая яву, всегда были на портах 8080 и 8443.
Пэтому если вы сисадмин, то вы про эти порты знаете уже давно, и проблем с ними не должно возникать.
Плюс, исторически сложилось что порты 80 и 443 для апача/нжинкса, а все остальные, включая яву, всегда были на портах 8080 и 8443.
Пэтому если вы сисадмин, то вы про эти порты знаете уже давно, и проблем с ними не должно возникать.
Позвольте, мы же говорим о порте, слушающим наружу в ожидании TLS? В этом случае есть стандарт: 443 порт, а все остальные варианты как раз для проприетарщины. И я скорее про затык на стороне пользователя говорил, у которого файрвол знает, что браузер должен ходить по 80 и 443 порту, ну еще по 8080 в виде исключения, а про 8443 он ничего не знает и соединения не пропустит.
Во всех пользовательских операционных системах исходящие соединения в большинстве случаев фаерволом никак не ограничиваются. А вот слушание порта как раз фаервол и режет, и все прослушивания по умолчанию заблокированы. Так что фаервол все прекрасно разрешает.
То есть, при соединении клиента — 443, 8443 — это внешние порты, а локально будет выбран случайный порт (например больше 50000) из доступных.
То есть, при соединении клиента — 443, 8443 — это внешние порты, а локально будет выбран случайный порт (например больше 50000) из доступных.
Ради интереса заглянул в исходники «демонстрирующие» работу TLS.
Код клиента: 87.971 байт исходники(!!!!)
Человек не ищет легкий путей. Наворачивает вои обертки вокруг стандартных классов. К месту не к месту прикручивает spring аспекты и бины.
Ужас…
Создание своего SSLContext из стандартного (SSLContext.getInstance(«TLS»)) со всеми опциональными наворотами (цепочка сертификатов сервера, ключ клиента) это 80 строк кода максимум.
Остальной код клиента, включая анализ командной строки, например, еще строк 100 от силы.
А дальше подставляй свой SSLContext либо вообще на уровень голого сокета, либо, если уж без любимого HTTP жить не можешь, в любой HTTP клиент (древний HttpURLConnection, apache http client, jersey http client, и т.д.).
+ еще строчка… две кода для HTTPS включающего/выключающего проверку имени хоста в сертфикате (для проксированных соединений).
Это что тренд такой писать многословный код, выполняющий простые вещи?
87.971 байт исходников на демо клиента… я до сих пор в шоке.
Код клиента: 87.971 байт исходники(!!!!)
Человек не ищет легкий путей. Наворачивает вои обертки вокруг стандартных классов. К месту не к месту прикручивает spring аспекты и бины.
Ужас…
Создание своего SSLContext из стандартного (SSLContext.getInstance(«TLS»)) со всеми опциональными наворотами (цепочка сертификатов сервера, ключ клиента) это 80 строк кода максимум.
Остальной код клиента, включая анализ командной строки, например, еще строк 100 от силы.
А дальше подставляй свой SSLContext либо вообще на уровень голого сокета, либо, если уж без любимого HTTP жить не можешь, в любой HTTP клиент (древний HttpURLConnection, apache http client, jersey http client, и т.д.).
+ еще строчка… две кода для HTTPS включающего/выключающего проверку имени хоста в сертфикате (для проксированных соединений).
Это что тренд такой писать многословный код, выполняющий простые вещи?
87.971 байт исходников на демо клиента… я до сих пор в шоке.
Hi Mike,
I am the repository maintainer and I want to provide some context for others regarding your opinion about the project. I don't speak Russian so I will drop this comment in English. I will also put the translation below.
First of all I feel honoured that someone wanted to share my project here, thank you very much!
I agree with you Mike that the client project is a bit complicated and the size is indeed also very big, but there is a reason for that! In the beginning it was just a small client which only had an apache http client example request and client configuration. But we all know that not everyone is just using apache http client. Therefore I wanted to add all http clients which I could find for java. But there are also a-lot developers who use Scala and Kotlin and I wanted to help those users too by giving them just basic example configurations. So the client repository is indeed big, but it contains over 40+ http clients for java, scala and kotlin and getting them all working in a single maven module is really tough… I just wanted to give other developers a single place to look for as a cheatsheet when they want to configure their http client with ssl.
I also want to say something about your comment regarding the sslcontext. I was initially just using the basic SSLContext from the jdk. But configuring over 40+ http client with a single base ssl configuration is nearly impossible. Therefore I created my own library as an abstract layer which can return different objects to configure all those http clients.
=============
Русский перевод Google:
Привет Майк,
Я сопровождаю репозиторий и хочу рассказать другим о вашем мнении о проекте. Я не говорю по-русски, поэтому оставлю этот комментарий на английском. Еще ниже поставлю перевод.
Прежде всего, для меня большая честь, что кто-то захотел поделиться моим проектом здесь, большое спасибо!
Я согласен с тобой, Майк, что клиентский проект немного сложен, и размер действительно тоже очень большой, но для этого есть причина! Вначале это был всего лишь небольшой клиент, у которого был только пример запроса клиента apache http и конфигурация клиента. Но все мы знаем, что не все используют просто http-клиент apache. Поэтому я хотел добавить все http-клиенты, которые я смог найти для java. Но есть также много разработчиков, которые используют Scala и Kotlin, и я хотел помочь этим пользователям, предоставив им только базовые примеры конфигураций. Таким образом, клиентский репозиторий действительно большой, но он содержит более 40+ http-клиентов для java, scala и kotlin, и заставить их всех работать в одном модуле maven действительно сложно… Я просто хотел дать другим разработчикам единое место для поиска for в качестве шпаргалки, когда они хотят настроить свой http-клиент с помощью ssl.
Я также хочу сказать кое-что о вашем комментарии относительно sslcontext. Изначально я просто использовал базовый SSLContext из jdk. Но настроить более 40+ http-клиентов с помощью одной базовой конфигурации ssl практически невозможно. Поэтому я создал свою собственную библиотеку как абстрактный слой, который может возвращать различные объекты для настройки всех этих http-клиентов.
I am the repository maintainer and I want to provide some context for others regarding your opinion about the project. I don't speak Russian so I will drop this comment in English. I will also put the translation below.
First of all I feel honoured that someone wanted to share my project here, thank you very much!
I agree with you Mike that the client project is a bit complicated and the size is indeed also very big, but there is a reason for that! In the beginning it was just a small client which only had an apache http client example request and client configuration. But we all know that not everyone is just using apache http client. Therefore I wanted to add all http clients which I could find for java. But there are also a-lot developers who use Scala and Kotlin and I wanted to help those users too by giving them just basic example configurations. So the client repository is indeed big, but it contains over 40+ http clients for java, scala and kotlin and getting them all working in a single maven module is really tough… I just wanted to give other developers a single place to look for as a cheatsheet when they want to configure their http client with ssl.
I also want to say something about your comment regarding the sslcontext. I was initially just using the basic SSLContext from the jdk. But configuring over 40+ http client with a single base ssl configuration is nearly impossible. Therefore I created my own library as an abstract layer which can return different objects to configure all those http clients.
=============
Русский перевод Google:
Привет Майк,
Я сопровождаю репозиторий и хочу рассказать другим о вашем мнении о проекте. Я не говорю по-русски, поэтому оставлю этот комментарий на английском. Еще ниже поставлю перевод.
Прежде всего, для меня большая честь, что кто-то захотел поделиться моим проектом здесь, большое спасибо!
Я согласен с тобой, Майк, что клиентский проект немного сложен, и размер действительно тоже очень большой, но для этого есть причина! Вначале это был всего лишь небольшой клиент, у которого был только пример запроса клиента apache http и конфигурация клиента. Но все мы знаем, что не все используют просто http-клиент apache. Поэтому я хотел добавить все http-клиенты, которые я смог найти для java. Но есть также много разработчиков, которые используют Scala и Kotlin, и я хотел помочь этим пользователям, предоставив им только базовые примеры конфигураций. Таким образом, клиентский репозиторий действительно большой, но он содержит более 40+ http-клиентов для java, scala и kotlin, и заставить их всех работать в одном модуле maven действительно сложно… Я просто хотел дать другим разработчикам единое место для поиска for в качестве шпаргалки, когда они хотят настроить свой http-клиент с помощью ssl.
Я также хочу сказать кое-что о вашем комментарии относительно sslcontext. Изначально я просто использовал базовый SSLContext из jdk. Но настроить более 40+ http-клиентов с помощью одной базовой конфигурации ssl практически невозможно. Поэтому я создал свою собственную библиотеку как абстрактный слой, который может возвращать различные объекты для настройки всех этих http-клиентов.
Hi Hakan,
The style of the arcticle «How to Easily Set Up Mutual TLS» is something like «HOWTO for beginners».
Such complicated example of client code will hide the simple idea of TLS key usage and TLS as OSI network layer.
This client code project is not for beginners. IMHO.
This is a good idea.
If an article with same githab link has topic somethimg as «Using TLS in all known HTTP clinet realisations», I set "+" and say nothing against.
The style of the arcticle «How to Easily Set Up Mutual TLS» is something like «HOWTO for beginners».
Such complicated example of client code will hide the simple idea of TLS key usage and TLS as OSI network layer.
This client code project is not for beginners. IMHO.
I just wanted to give other developers a single place to look for as a cheatsheet when they want to configure their http client with ssl.
This is a good idea.
If an article with same githab link has topic somethimg as «Using TLS in all known HTTP clinet realisations», I set "+" and say nothing against.
Разработчик теряет контроль над тем, каким приложениям разрешено обращаться к его приложению. Разрешение даётся любому приложению, у которого есть подписанный сертификат от удостоверяющего центра.
А что, отозванные сертификаты (CRL) уже отменили?
Здесь crl ни при чем. Имеется ввиду, что если сертификаты подписываешь ты, то ты и контролируешь кто имеет доступ. А если сертификаты подписывет кто-то другой, ты ничего не контролируешь, просто доверяешь. :)
Ну и тем-же списком отозванных заведует тот кто подписывает.
Ну и тем-же списком отозванных заведует тот кто подписывает.
В статье разработчик подписывает сам сертификаты, потому я рассматриваю именно этот случай. Вполне может быть (и скорее всего даже будет) ситуация когда доступ нужно отобрать. И вот тут как раз несотыковка, так как из текста следует что если есть сертификат — значит есть доступ и с этим ничего не сделаешь. Вот тут-то и приходит спасительный crl. Еще можно банально, например, резать доступ по тому же CN из сертификата.
Либо же я неправильно трактую фразу «Разработчик теряет контроль над тем, каким приложениям разрешено обращаться к его приложению.»
Либо же я неправильно трактую фразу «Разработчик теряет контроль над тем, каким приложениям разрешено обращаться к его приложению.»
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Простая настройка взаимной проверки подлинности клиента и сервера с использованием TLS