Empty response for ru/uk.wikipedia.org

[theromis]

Just duplicating my previous question/problem report.

Getting empty response for ru/uk.wikipedia.org

SNI peek: [uk.wikipedia.org] [complete], fd=44
Connecting to [198.35.26.96]:443
===> Original server certificate:
Subject DN: /CN=*.wikipedia.org
Common Names: *.wikipedia.org/*.m.mediawiki.org/*.m.wikibooks.org/*.m.wikidata.org/*.m.wikimedia.org/*.m.wikinews.org/*.m.wikipedia.org/*.m.wikiquote.org/*.m.wikisource.org/*.m.wikiversity.org/*.m.wikivoyage.org/*.m.wiktionary.org/*.mediawiki.org/*.planet.wikimedia.org/*.wikibooks.org/*.wikidata.org/*.wikimedia.org/*.wikimediafoundation.org/*.wikinews.org/*.wikipedia.org/*.wikiquote.org/*.wikisource.org/*.wikiversity.org/*.wikivoyage.org/*.wiktionary.org/*.wmfusercontent.org/mediawiki.org/w.wiki/wikibooks.org/wikidata.org/wikimedia.org/wikimediafoundation.org/wikinews.org/wikipedia.org/wikiquote.org/wikisource.org/wikiversity.org/wikivoyage.org/wiktionary.org/wmfusercontent.org
Fingerprint: EF:9C:F2:C9:64:3B:E7:20:E5:5F48:BD:BF:8C:96:5E:79:7B:F0:05
Certificate cache: MISS
===> Forged server certificate:
Subject DN: /CN=*.wikipedia.org
Common Names: *.wikipedia.org/*.m.mediawiki.org/*.m.wikibooks.org/*.m.wikidata.org/*.m.wikimedia.org/*.m.wikinews.org/*.m.wikipedia.org/*.m.wikiquote.org/*.m.wikisource.org/*.m.wikiversity.org/*.m.wikivoyage.org/*.m.wiktionary.org/*.mediawiki.org/*.planet.wikimedia.org/*.wikibooks.org/*.wikidata.org/*.wikimedia.org/*.wikimediafoundation.org/*.wikinews.org/*.wikipedia.org/*.wikiquote.org/*.wikisource.org/*.wikiversity.org/*.wikivoyage.org/*.wiktionary.org/*.wmfusercontent.org/mediawiki.org/w.wiki/wikibooks.org/wikidata.org/wikimedia.org/wikimediafoundation.org/wikinews.org/wikipedia.org/wikiquote.org/wikisource.org/wikiversity.org/wikivoyage.org/wiktionary.org/wmfusercontent.org
Fingerprint: 71:DE:C3:BA:BD:25:8A:21:1E:B479:9F:73:F9:04:39:97:6A:A2:64
HTTPS connected to [198.35.26.96]:443 TLSv1.3 TLS_AES_256_GCM_SHA384
CLIENT_RANDOM C2C1A9CF540DF349865C2FA4F90D63CEA758981FCD97C69C65EBEA44EE4BAD6D 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Certificate cache: KEEP (SNI match or target mode)
Certificate cache: KEEP (SNI match or target mode)
HTTPS connected to [198.35.26.96]:443 TLSv1.3 TLS_AES_256_GCM_SHA384
CLIENT_RANDOM 92D478F9DE26B3E10A955D5516155E687E16B920B2145388F3882104D80C264B 49C0775704A69A642E84A2E6BD52B18ECDD7F93FE939B011E8C72DA254888DB9D1E00F3102D4DEB347397DD64E757E46
SSL_free() in state 00000001 = 0001 = SSLOK  (SSL negotiation finished successfully) [accept socket]
SSL_free() in state 00000001 = 0001 = SSLOK  (SSL negotiation finished successfully) [connect socket]
^CReceived signal 2
Main event loop stopped (reason=2).
Received privsep req type 00 sz 1 on srvsock 8
Child pid 103332 exited with status 0

same for ru.wikipedia.org

roman@macmini:~$ sslproxy -V
SSLproxy  (built 2022-05-17)
------------------------------------------------------------------------------
WARNING: Something is wrong with the version compiled into sslproxy!
The version should contain a release number and/or a git commit reference.
If using a package, please report a bug to the distro package maintainer.
------------------------------------------------------------------------------
Copyright (c) 2017-2022, Soner Tari <[email protected]>
https://github.com/sonertari/SSLproxy
Copyright (c) 2009-2019, Daniel Roethlisberger <[email protected]>
https://www.roe.ch/SSLsplit
Build info: V:GIT
Features: -DHAVE_NETFILTER
NAT engines: netfilter* tproxy
netfilter: IP_TRANSPARENT IP6T_SO_ORIGINAL_DST
Local process info support: no
compiled against OpenSSL 1.1.1f  31 Mar 2020 (1010106f)
rtlinked against OpenSSL 1.1.1f  31 Mar 2020 (1010106f)
OpenSSL has support for TLS extensions
TLS Server Name Indication (SNI) supported
OpenSSL is thread-safe with THREADID
OpenSSL has engine support
Using SSL_MODE_RELEASE_BUFFERS
SSL/TLS protocol availability: tls10 tls11 tls12 tls13
SSL/TLS algorithm availability: !SHA0 RSA DSA ECDSA DH ECDH EC
OpenSSL option availability: SSL_OP_NO_COMPRESSION SSL_OP_NO_TICKET SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION SSL_OP_TLS_ROLLBACK_BUG
compiled against libevent 2.1.11-stable
rtlinked against libevent 2.1.11-stable
compiled against libnet 1.1.6
rtlinked against libnet 1.1.6
compiled against libpcap n/a
rtlinked against libpcap 1.9.1 (with TPACKET_V3)
compiled against sqlite 3.31.1
rtlinked against sqlite 3.31.1
4 CPU cores detected
roman@macmini:~$

Happy to help with fix just don't know where to look.

[sonertari]

Since I don't have your test environment, I cannot test it myself. But you can enable DEBUG_PROXY (and DEBUG_OPTIONS) switches in Mk/main.mk, recompile, and then start sslproxy with the -D4 option. Sslproxy will print very verbose debug logs, which I hope will help you understand the reason for this issue. You can post those debug logs here if you want.

[theromis]

out.log
turned all debugging on, on request

romans-mbp.lan 11:02:44.265 > ~ curl https://uk.wikipedia.org/wiki/%D0%93%D0%BE%D0%BB%D0%BE%D0%B2%D0%BD%D0%B0_%D1%81%D1%82%D0%BE%D1%80%D1%96%D0%BD%D0%BA%D0%B0
curl: (52) Empty reply from server
romans-mbp.lan 11:09:41.516 > ~

log not shows any error, nginx log is clear, no errors no access log entries, seems like something between sslproxy and nginx

[AndyKozlovskyi]

I had a similar issue, as I remember was connected with OCSP detection.
Try this: #26