Hi All,
No reply ?
Do we have to leave with this mega/crazy bug ?
Is there someone in the Squid team able to have a look to this problem or
nobody care ?
Thanks in advance.
Bye Fred
--
View this message in context:
http://squid-web-proxy-cache.1019090.n4.nabble.com/Random-SSL-bump-DB-corrupt
Hi Amos, All,
We have done as you indicate, but the index.tx is still corrupted, have a
look:
*V 250406120057Z 2C564651B40D1F4F6CAFFF06EA8B201580E3B678
unknown
/CN=173.194.65.84+Sign=signTrusted+SignHash=SHA256
V 250406120057Z 71664F2E27C4E321B2A4F59EA3971D70
Yuri,
We’re trying that :
- Tproxy
- ssl_bump bump all
does not work.
We have followed the squid wiki regarding iptables rules, sysctl, etc…
Instead “ssl_bump bump all”, if we use “ssl_bump server-first all” , it works,
the https is decrypted.
So is the tproxy com
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I think,first you can try new stage-based SSL bump with 3.5.x. To do
that you must identify problem sites.
If there is no results, you can simple bypass problem sites without bump.
Whole server-first bump, on Squid 3.5.x especially, is not so go
Yuri,
So what’s next ?
Do you mean we must “do-not-ssl-bump” wrong certificats ?
And if a certificate not yet identified is requested by an user it’ll crash the
Squid ?
Any idea how to fix that issue ?
Thanks in advance.
Bye Fred
De : Yuri Voinov [mailto:yvoi...@gmail.com]
Envo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
- From my experience, it may occur as a result of forming the fake
certificate zero length (in the case of the SQUID can not complete its
formation for any reason).
In turn, the formation of such a certificate occurs in particular due to
any error
Yury,
I checked the source code (3.4/3.5) ssl_crtd, the default size is 2048.
-b fs_block_size File system block size in bytes. Need for processing
natural size of certificate on disk. Default value is
2048 bytes."
/**
\ingroup ssl_crtd