安卓客户端Bug

[simplerick-simplefun]

环境：
客户端
Redmi K50 Android 12 MIUI 13 官方稳定版ROM (ARMv8)
（如果使用PC windows 11 客户端，则无此问题）

./shadow-tls-aarch64-unknown-linux-musl client --listen "0.0.0.0:8243" --server "x.x.x.x:8443" --sni "oracle.com" --password "yyyyyyyy"

Log:
2022-11-20T19:04:57.401453Z INFO shadow_tls: Client is running!
Listen address: 0.0.0.0:8243
Remote address: x.x.x.x:8443
TLS server name: oracle.com
2022-11-20T19:05:01.524408Z INFO shadow_tls: Accepted a connection from 127.0.0.1:41416
2022-11-20T19:05:01.672460Z INFO shadow_tls: Accepted a connection from 127.0.0.1:41420
2022-11-20T19:05:01.954111Z WARN rustls::conn: Sending fatal alert BadCertificate
2022-11-20T19:05:01.954981Z INFO shadow_tls: Accepted a connection from 127.0.0.1:41424
2022-11-20T19:05:02.103545Z WARN rustls::conn: Sending fatal alert BadCertificate
2022-11-20T19:05:02.463809Z WARN rustls::conn: Sending fatal alert BadCertificate
2022-11-20T19:05:02.466068Z INFO shadow_tls: Accepted a connection from 127.0.0.1:41428
2022-11-20T19:05:02.977163Z WARN rustls::conn: Sending fatal alert BadCertificate
2022-11-20T19:05:02.979236Z INFO shadow_tls: Accepted a connection from 127.0.0.1:41432
2022-11-20T19:05:03.489424Z WARN rustls::conn: Sending fatal alert BadCertificate
2022-11-20T19:05:03.491310Z INFO shadow_tls: Accepted a connection from 127.0.0.1:41436
2022-11-20T19:05:04.001440Z WARN rustls::conn: Sending fatal alert BadCertificate

我查了一下，oracle.com的CA根证书是Digicert，对比了序列号，我手机上有这个预装的受信任根证书。
是不是rusttls无法读取安卓的cert store?

[ihciah]

这个原因我不是很确定，我印象中应该会使用 webpki-roots 包提供的根证书，你可以尝试升级一下这个包然后编译运行看看。
不过根证书这种应该不会有近期的改动才对，有点奇怪。

[simplerick-simplefun]

我刚刚用最新的版本试了一下，还是这个问题。有空我自己编译试试。
也麻烦作者@ihciah看下，具体查验证书的机制是什么？是内置的证书，还是查验系统的证书？

客户端：
2023-01-06T07:45:40.331211Z INFO shadow_tls: Accepted a connection from 127.0.0.1:60556
2023-01-06T07:45:40.610067Z DEBUG shadow_tls::client: tcp connected, start handshaking
2023-01-06T07:45:40.610528Z DEBUG rustls::client::hs: No cached session for DnsName(DnsName(DnsName("oracle.com")))
2023-01-06T07:45:40.611471Z DEBUG rustls::client::hs: Not resuming any session
2023-01-06T07:45:41.218272Z DEBUG rustls::client::hs: ALPN protocol is None
2023-01-06T07:45:41.218558Z DEBUG rustls::client::hs: Using ciphersuite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
2023-01-06T07:45:41.218678Z DEBUG rustls::client::tls12::server_hello: Server supports tickets
2023-01-06T07:45:41.425015Z DEBUG rustls::client::tls12: ECDHE curve is ECParameters { curve_type: NamedCurve, named_group: secp256r1 }
2023-01-06T07:45:41.425348Z DEBUG rustls::client::tls12: Server DNS name is DnsName(DnsName(DnsName("oracle.com")))
2023-01-06T07:45:41.425644Z WARN rustls::conn: Sending fatal alert BadCertificate
2023-01-06T07:45:41.429892Z INFO shadow_tls: Accepted a connection from 127.0.0.1:60560
2023-01-06T07:45:41.633511Z DEBUG shadow_tls::client: tcp connected, start handshaking
2023-01-06T07:45:41.633740Z DEBUG rustls::client::hs: No cached session for DnsName(DnsName(DnsName("oracle.com")))
2023-01-06T07:45:41.634134Z DEBUG rustls::client::hs: Not resuming any session
2023-01-06T07:45:42.244459Z DEBUG rustls::client::hs: ALPN protocol is None
2023-01-06T07:45:42.244564Z DEBUG rustls::client::hs: Using ciphersuite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
2023-01-06T07:45:42.244601Z DEBUG rustls::client::tls12::server_hello: Server supports tickets
2023-01-06T07:45:42.448556Z DEBUG rustls::client::tls12: ECDHE curve is ECParameters { curve_type: NamedCurve, named_group: secp256r1 }

服务端：
2023-01-06T07:45:40.630626Z INFO shadow_tls: Accepted a connection from x.x.x.x:54828
2023-01-06T07:45:40.754432Z DEBUG shadow_tls::server: handshake server connected
2023-01-06T07:45:40.754588Z DEBUG shadow_tls::server: read header with type 22 and length 236
2023-01-06T07:45:40.754635Z DEBUG shadow_tls::server: copied data with length 236
2023-01-06T07:45:41.446411Z DEBUG shadow_tls::server: read header with type 21 and length 2
2023-01-06T07:45:41.446525Z DEBUG shadow_tls::server: copied data with length 2
2023-01-06T07:45:41.653845Z INFO shadow_tls: Accepted a connection from x.x.x.x:54832
2023-01-06T07:45:41.775112Z DEBUG shadow_tls::server: handshake server connected
2023-01-06T07:45:41.775570Z DEBUG shadow_tls::server: read header with type 22 and length 236
2023-01-06T07:45:41.775809Z DEBUG shadow_tls::server: copied data with length 236
2023-01-06T07:45:42.468629Z DEBUG shadow_tls::server: read header with type 21 and length 2
2023-01-06T07:45:42.469043Z DEBUG shadow_tls::server: copied data with length 2

[mhasgari]

Hi
I faced the warning yesterday, it was from defining the TLS environment variable in the server and client different, by mistake!
:)

[simplerick-simplefun]

Hi I faced the warning yesterday, it was from defining the TLS environment variable in the server and client different, by mistake! :)

Hi, would you mind share more detail on the problem and solution? Thanks.

[mhasgari]

Hi I faced the warning yesterday, it was from defining the TLS environment variable in the server and client different, by mistake! :)

Hi, would you mind share more detail on the problem and solution? Thanks.

Hi
Just didn't define these two environment variables the same, by mistake!
Maybe you made this mistake two, is that so?

[simplerick-simplefun]

Hi I faced the warning yesterday, it was from defining the TLS environment variable in the server and client different, by mistake! :)

Hi, would you mind share more detail on the problem and solution? Thanks.

Hi Just didn't define these two environment variables the same, by mistake! Maybe you made this mistake two, is that so?

Well I simply downloaded the compiled executables from release page and run them. I didn't define any enviroment varaibles.
Do you mean defining enviroment varaibles at compile time or defining at run time?
And which enviroment variables are you referring to?

[mhasgari]

I used the Docker version, but doesn't make any difference! I meant TLS, which should be set like TLS=www.google.com:443 on the server and TLS=www.google.com on the client. I have set them not as same, by mistake.
The executable version should have an input for this reason. Are you sure you have set them correctly and as the same?

[ihciah]

遇到问题的朋友们可以抓下包看看，担心敏感信息泄漏可以发送至我的邮箱，有空会处理。

If you meet the same problem, you can capture the packets and send it to my email, which can be found in my github profile. I will process it when I have time.

[ihciah]

可以尝试一下最新版本，可能首最近修复的一个 Bug 影响。

[simplerick-simplefun]

可以尝试一下最新版本，可能首最近修复的一个 Bug 影响。

刚刚测试了一下，还是不行，但是log的内容变了，客户端服务端都是Info: Accepted a connection + Relay finished
客户端：
2023-02-08T07:26:54.987228Z INFO shadow_tls::client: Accepted a connection from 127.0.0.1:49446
2023-02-08T07:26:55.046474Z INFO shadow_tls::client: Relay for 127.0.0.1:49446 finished
服务端：
2023-02-08T07:25:50.854429Z INFO shadow_tls::server: Accepted a connection from [::ffff:x.x.x.x]:34372
2023-02-08T07:25:51.311966Z INFO shadow_tls::server: Relay for [::ffff:x.x.x.x]:34372 finished
服务端收到手机发来的流量后，不会转发给本地的shadowsocks服务端口，反而会去relay访问伪装的sni站。
我用tcpdump和ss确认了这一点。
服务端同样的配置不变，用windows上的singbox来访问，就完全没问题。

这次我怎么设置RUST_LOG都只有INFO了，不显示任何DEBUG/TRACE级别的log，是代码改了吗？