Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Неверный сертификат #115

Open
vadimkara opened this issue Aug 1, 2022 · 7 comments
Open

Неверный сертификат #115

vadimkara opened this issue Aug 1, 2022 · 7 comments

Comments

@vadimkara
Copy link

image

На некторых сайтх при переходе по ссылке на субдомены программа выдает сертификат не на тот днс что указан в ссылке

image

@krlvm
Copy link
Owner

krlvm commented Aug 1, 2022

Эта проблема связана с Cloudflare, когда модификация SNI выключена, она отсутствует. Думаю, что можно с этим сделать.

@pundoo
Copy link

pundoo commented May 13, 2023

Эта проблема связана с Cloudflare, когда модификация SNI выключена, она отсутствует. Думаю, что можно с этим сделать.

I'm facing same issue. Any workaround for this (with sni, not chuck)?

@krlvm
Copy link
Owner

krlvm commented May 13, 2023

Not yet, but you can disable these warnings in Chrome (this is not a good way though)

@krlvm krlvm changed the title Невереный сертификат Неверный сертификат May 13, 2023
@pundoo
Copy link

pundoo commented May 14, 2023

Not yet, but you can disable these warnings in Chrome (this is not a good way though)

Disabling warnings don't seems to work. These sites are basically behind CDNs, that strictly requires the correct SNI field to serve the right certificate (and the right server to connect to?). Faking SNI simply breaks this mechanism.

I don't know (in-depth) exactly how the HTTPS connection establishes but, is it somehow possible to generate the (self-signed) cert from client request SNI/host (Fiddler does it), so that the CN matches and the handshake is successful. Then after that, somehow tell server the actual site we're trying to connect to via host header or something?

@krlvm
Copy link
Owner

krlvm commented May 14, 2023

Disabling warnings don't seems to work. These sites are basically behind CDNs, that strictly requires the correct SNI field to serve the right certificate (and the right server to connect to?). Faking SNI simply breaks this mechanism.

Yes, that's the problem. IIRC I wrote a detailed explaination in other thread some time ago.

I don't know (in-depth) exactly how the HTTPS connection establishes but, is it somehow possible to generate the (self-signed) cert from client request SNI/host (Fiddler does it), so that the CN matches and the handshake is successful. Then after that, somehow tell server the actual site we're trying to connect to via host header or something?

MITM is done by LittleProxy and its extension LittleProxy-mitm. Certificate generation is requested here, and it the certificates changes then, which is the problem. I tried to debug this previously, but I did not succeed. I will try again today.

@pundoo
Copy link

pundoo commented May 14, 2023

MITM is done by LittleProxy and its extension LittleProxy-mitm. Certificate generation is requested here, and it the certificates changes then, which is the problem. I tried to debug this previously, but I did not succeed. I will try again today.

Did some read up and seems like it should be fairly simple. We just have to get the SNI/host from the client request and use it as the COMMON_NAME (CN) for self generated certificate (instead of using CN received from server). I don't know Java that much, otherwise I'd test this approach..

@krlvm
Copy link
Owner

krlvm commented May 15, 2023

Yes that's it. Though I don't see a way to obtain it yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants