LINUX.ORG.RU

Не могу залогиниться на сайте китайского магазина

 , ,


1

2

Ситуация такая, похоже с недавних пор aliexpress оставил поддержку только небезопасных шифров.
И если зайти на сайт и попробовать залогиниться, то получшь сообщение:

An error occurred during a connection to login.aliexpress.com. Cannot communicate securely with peer: no common encryption algorithm(s). (Error code: ssl_error_no_cypher_overlap)

Если принудительно включить поддержку RC4, то залогиниться можно.
Попрошу протестировать:
Для этого нужно зайти на aliexpress.com и нажать на «Sign in», ну а потом скорей всего нажать на замочек, подробнее и в технических деталях будет выбранный cipher suite. В зависимости от версии и от браузера, но в идеале браузер должен выбирать самый безопасный из доступных сервером и поддерживаемых браузером cipher suite.
Прощу скопировать его в данную тему. Интересно там у всех cipher suite с RC4.

в идеале браузер должен выбирать самый безопасный из доступных сервером и поддерживаемых браузером cipher suite

Браузер ничего не выбирает напрямую; он лишь отправляет серверу список допустимых cipher suites, а уже тот делает выбор или же обрывает хендшейк.

edigaryev ★★★★★ ()
Последнее исправление: edigaryev (всего исправлений: 1)
Ответ на: комментарий от edigaryev

Нет, браузер всегда старается выбрать самый стойкий cipher suite, и TLS, по крайней мере в последних версиях firefox. А потом уже идет деградация, до приемлемого для обеих сторон cipher suite. А если сервер еще и поддерживает

https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00#section-3

anonymous_sama ★★★★★ ()
Ответ на: комментарий от edigaryev

Там есть одно:

OpenSSL 1.0.1h TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) FS 128

Остальное все RC4, а в поддерживаемых протоколах

TLS 1.2 No.

Странно.

anonymous_sama ★★★★★ ()
openssl s_client -connect login.aliexpress.com:443
SSL-Session:
    Protocol  : TLSv1
    Cipher    : RC4-SHA
spunky ★★ ()

Короче дабы не писать еще одну кнопку, для включения, выключения RC4, придется использовать отдельный профиль для данного магазина. Но до этого они поддерживали и другие cipher suite, иначе я бы стал получать ошибку еще раньше.
Странно это. И главное зачем, когда наверняка у правительства есть физический доступ к серверу.
Или все-таки, если нет, то это все объясняет.

Issuer VeriSign

anonymous_sama ★★★★★ ()
Ответ на: комментарий от anonymous_sama

Нет, браузер всегда старается выбрать самый стойкий cipher suite, и TLS

Прочитай еще раз что ты написал:

браузер должен выбирать самый безопасный из доступных сервером и поддерживаемых браузером cipher suite

Браузер не знает какие cipher suites поддерживает сервер, именно поэтому в контексте TLS, cipher suite который будет использоваться для сессии выбирается сервером, а не браузером.

edigaryev ★★★★★ ()
Ответ на: комментарий от edigaryev

Да, но от поддержки cipher suites браузером очень многое зависит, и браузер сделает downgrade только если разорвется handshake. Вот нашел:

At this point, a ChangeCipherSpec message is sent by the client, and the client copies the pending Cipher Spec into the current Cipher Spec. The client then immediately sends the Finished message under the new algorithms, keys, and secrets. In response, the server will send its own ChangeCipherSpec message, transfer the pending to the current Cipher Spec, and send its Finished message under the new Cipher Spec. At this point, the handshake is complete, and the client and server may begin to exchange application layer data. (See flow chart below.)

Браузер выбирает, какой cipher использоваться, а не сервер.

anonymous_sama ★★★★★ ()
Ответ на: комментарий от anonymous_sama

Нашел более изящное решение:
В 'security.tls.insecure_fallback_hosts' добавить login.aliexpress.com

anonymous_sama ★★★★★ ()
Ответ на: комментарий от anonymous_sama

Вот нашел:
In response, the server will send its own ChangeCipherSpec message, transfer the pending to the current Cipher Spec, and send its Finished message under the new Cipher Spec.

Ну и что?

edigaryev ★★★★★ ()
Ответ на: комментарий от edigaryev

А то, что cipher suite, выбирается как со стороны клиента, так и со стороны сервера. И браузер вполне в курсе какой cipher ему использовать. И следуещее утверждение, является полным бредом:

Браузер не знает какие cipher suites поддерживает сервер

anonymous_sama ★★★★★ ()
Ответ на: комментарий от anonymous_sama

А то, что cipher suite, выбирается как со стороны клиента, так и со стороны сервера.

«ChangeCipherSpec message» который ты привел не имеет никакого отношения к выбору чего-либо, это просто такой своеобразный маркер:

The change cipher spec protocol exists to signal transitions in ciphering strategies.

И браузер вполне в курсе какой cipher ему использовать.

Еще бы, ведь сервер сообщил клиенту о своем выборе в ServerHello :-)

И следуещее утверждение, является полным бредом:

Аргументы в студию.

edigaryev ★★★★★ ()
Ответ на: комментарий от edigaryev

Браузер не знает какие cipher suites поддерживает сервер

Сервер сообщает браузеру какой cipher использовать, вот только браузер сам выбирает, какой именно использовать. (да на основании, того cipher suite о котором они сов) Если бы браузер не имел представления, о cipher suites, которые поддерживает сервер, то либо соединение не произошло, либо он просто перебрал все cipher suites подряд пока успешный handshake не состоялся, как и делает ssltest. Но и в этом случае на каждый отдельный cipher, вся процедура будет проходить обычно просто список из одного cipher suite.
Да заметь клиент, необязательно должен вести себя, как ему говорит сервер и в Client Hello message может быть фиктивный список cipher suites. Клиент, может быть даже не браузером, а какой-нибудь бот и так далее, в том же браузере многое зависит от настроек, и в случае чего он сразу будет бить по тормозам еще до облома с handshake.
Это как диалог, клиент договаривается, с сервером, они знакомятся и жмут друг-друга по рукам выбрав cipher suite.

anonymous_sama ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.