RC4, may be. In practice, too restrictive security usually leads various issues, ever for big vendor site, like MS (some of this sites AFAIK still using RC4). To be related to your questions - yes, in theory it is possible to get security issue in this case. But it is require deep investigation. If you are concerned - just take a look onto default openssl cipher's list. And compare it with recommended forefront security. 07.12.2017 1:56, Hugo Saavedra пишет: > solution finded: we commented the sslproxy_cipher line and it works! > is there any security issues if we left the default options for this variable? > > thanks > Hugo > > 2017-12-06 16:21 GMT-03:00 Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx>: >> On 12/06/2017 12:06 PM, Hugo Saavedra wrote: >>> 2017/12/06 16:02:37 kid1| Error negotiating SSL connection on FD 61: >>> error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca >>> (1/0) >> You may be able to fix this problem by updating your collection of >> public CA certificates. Squid uses CA certificates to validate >> certificates presented by origin servers. You may be able to confirm >> that your collection is stale and know more (e.g., which CA certificate >> is unknown) if you can map the above error to an access.log entry that >> would give you the origin server name to interrogate. >> >> Similar reasoning applies to other SSL-related cache.log errors as well, >> but troubleshooting them may require more efforts (e.g., starting with a >> higher debugging levels and/or packet captures). >> >> Alex. > > -- "Some people, when confronted with a problem, think «I know, I'll use regular expressions.» Now they have two problems." --Jamie Zawinsk ************************** * C++: Bug to the future * **************************
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
