Дано:
Есть сайт https://www.bababi.ru
Запускаю wireshark, открываю firefox, гуляю по вышеуказанному сайту - вижу в wireshark все соединения по TLS 1.3
Останавливаю задачу в wireshark (firefox не закрываю), запускаю новую задачу в wireshark, продолжаю навигацию по этому сайту - вижу в wireshark все соединения по TLS 1.2 !
Как так-то ?
А почему на клиентах никто не пользуется ?
В Убунту например в Огнелисе одним кликом в about:config. Даже в windows-10 в Edge включается парой нажатий.
Хлеба не простит, ничего не ломает при сёрфинге в интернете - а те немногие сайты где сервер под эту фичу настроили чуть быстрее будут открываться.
Так почему не включает-то никто ?
Не знают ? Лень ?
Если в postfix эта проблема решается добавлением
tls_ssl_options = NO_COMPRESSION, 0x40000000То в exim совершенно непонятно как :(
Есть идеи ?
1. На сайте программы указано что с ipv6 работает без проблем и свежих жалоб нет по этому поводу.
2. У меня в системе (ubuntu 18.04) ping6 и traceroute6 работают без ошибок.
3.
Если
python3 -m sslyze --regular google.comВсё работает.
4.
Но
python3 -m sslyze --regular ipv6.google.comВыдаёт:
WARNING: gaierror: -9; discarding corresponding tasksНу и с другими ipv6 не работает даже если в виде ip а не домена проверять.
В чём может быть проблема ?
Ubuntu 18.04
Installing new version of config file /etc/apparmor.d/usr.lib.snapd.snap-confine.real ...
md5sum: /etc/apparmor.d/usr.lib.snapd.snap-confine: No such file or directory
snapd.failure.service is a disabled or a static unit, not starting it.
snapd.snap-repair.service is a disabled or a static unit, not starting it.
Что с этим делать и надо ли что-то делать ?
Гуглил: Советы через purge сносить snap. Но совсем не хочется это делать - у меня из под него nextcloud стоит.
openssl 1.1.1 ubuntu 18.04
Выполняю:
openssl s_client -connect site.ru:443
Ответ:
Verification error: unable to get local issuer certificate
Если же выполняю:
openssl s_client -connect site.ru:443 -CAfile /etc/ssl/certs/ca-certificates.crt
То всё нормально.
Что ему не нравится то ?
Если в openssl.cnf тот же самый путь для СА прописан:
[ са ]
default_ca = CA_default
[ CA_default ]
Dir = /etc/ssl
Certs = $dir/certs
crl_dir = $dir/crl
database = $dir/index.txt
new_certs_dir = $dir/newcerts
certificate = $dir/certs/ca-certificates.crt
serial = $dir/serial
Так что же ему не нравится то ?
Что сделал:
1. Установил
2. В resolv.conf сменил nameserver на:
127.0.01 и ::1
3. service stubby enable, service stubby start
4. service stubby status показывает что он работает
Но никакого DOT и в помине нет на любых сервисах проверки
Что делать ?
1. Эта директива появилась в nginx версии 1.15.3 (ошибки исправлены в версии 1.15.8)
Судя по описании существенно уменьшае время повторных ssl «рукопожатий».
2. Сервисы проверки уже научились определять включена ли эта опция:
https://www.htbridge.com/ssl/?id=kqokkuK1
«Server's TLSv1.3 Early Data (RFC 8446, page 17) is properly implemented»
3. Но вот примечание меня смущает:
«Proper implementation of the Early Data allows a client to use zero round trip (0-RTT) and mitigates some vectors of the Replay Attack.»
На сайте nginx советуют:
" Запросы, отправленные внутри early data, могут быть подвержены атакам повторного воспроизведения (replay). Для защиты от подобных атак на уровне приложения необходимо использовать переменную $ssl_early_data.
proxy_set_header Early-Data $ssl_early_data; "
Не понял - этот хедер куда добавить надо в случае вебсервера на свзке nginx и apache ? В nginx ? В apache ?
И вообще насколько страшна эта уязвимость ?
Отказываться просто так от фишки уменьшающий время подключения к сайту не хочется же.
С «ask» всё понятно, а вот «yes» и «true» выдают абсолютно одинаковый результат.
Так и должно быть ?
Для сервер-клиент соединения:
1.
openssl s_client -connect ххх.ххх.ххх.ххх:5222 -starttls xmpp </dev/null
Результат ОК
2.
openssl s_client -connect domain.ru:5222 -starttls xmpp </dev/null
Результат ОК
Но для сервер-сервер соединения:
1.
openssl s_client -connect domain.ru:5269 -starttls xmpp-server </dev/null
Результат ОК
2.
openssl s_client -connect xxx.xxx.xxx.xxx:5269 -starttls xmpp-server </dev/null
Результат - нет tls
(xxx.xxx.xxx.xxx соответствует domain.ru разумеется)
Это нормально?
Я знаю что если есть такая связка то все мануалы твердят что в этом случае keep-alive в apache надо отключать так как он прожорлив до оперативки и лучше её высвободить для других нужд.
Но если команда free -h выдаёт:
total used free shared buff/cache available Mem: 62G 2,6G 50G 325M 9,1G 59G Swap: 0B 0B 0B
То может имеет смысл не отключать ?
В vhost .conf nginx добавил:
upstream http_backend {
server 127.0.0.1:8080;
keepalive 100;
}
location / {
proxy_pass http://http_backend;
proxy_redirect http://http_backend /;
proxy_http_version 1.1;
proxy_set_header Connection "";
}
В nginx.conf для входящих соединений:
keepalive_timeout 65;
В httpd.conf добавил:
KeepAlive On
KeepAliveTimeout 65
Добавил в настройки лога apache %k и вижу что всё заработало.
Визуально на глаз ничего не поменялось, но чисто теоретически навигация по сайту чуть быстрее должна была стать ?
Failed to fetch http://download.opensuse.org/repositories/home:/stevenpusser/xUbuntu_18.04/Re... The following signatures were invalid: EXPKEYSIG 0FAD31CA8719FCE4 home:stevenpusser OBS Project <home:stevenpusser@build.opensuse.org>
И что с этим делать ? Вчера всё нормально - сегодня появилось.
Как безопасно всё сделать с сохранением всех настроек .conf ?
P.S.
Если возможно пошагово (мануал в сети ненагуглил :( )
Зачем админы моего сервера сделали данное правило ?
-A FORWARD -s IP моего домашнего интернета/32 -j DROP
В input блокировки этого IP нет, по ssh, ftp захожу - всё нормально. С почтовым сервером с этого IP работаю - всё нормально.
Не могу понять смысл этого ограничения ?
jail.local:
Проверка failregex из exim_auth (filter.d):
Ничего не забыл для параноидального режима ?
Хочу вот это:
https://www.tecmint.com/guacamole-access-remote-linux-windows-machines-via-we...
Установил сам Tomcat9 (работает)
Установил guacamole-server-0.9.14
ssh через guacamole работает а rdp нет !
Что дальше делать не знаю :(
Подскажите или лучше сделайте (платно разумеется) чтобы таки я получил доступ по RDP через вэб-интерфейс.
Возник вопрос:
В чём причина что во всех faq и хелпах сертификат для ftps пишут создавать в openssl самоподписанный. Почему взять и не использовать сертификат домена если он уже есть? Или есть какие то проблемы в этом случае?
На финальной версии openssl 1.1.1
Есть какой-нибудь сервис наподобие bertal но для ipv6 ?
Пару лет эта троица тестировала и вот выкатила новую фичу.
1.
ТТХ MTA-STS
2.
ТТХ SMPT-TLSRPT
3. Валидатор этой фичи validator
Если мой домен babai.ru подставить то можно увидеть как когда всё правильно !
| следующие → |