similar to: SSL Renegotiation Attack "Disabling reneotiation"

Hello. I've just tested my system that runs dovecot 2.3.4.1 on debian buster with testssl.sh (https://testssl.sh/) and is says: Secure Renegotiation (CVE-2009-3555) not vulnerable (OK) Secure Client-Initiated Renegotiation VULNERABLE (NOT ok), potential DoS threat Is this a configuration or a compilation issue and how to solve it? -- sergio.

On Thu, Mar 10, 2016 at 12:30 PM, Osiris <dovecot at flut.demon.nl> wrote: > On 09-03-16 13:14, djk wrote: >> On 09/03/16 10:44, Florent B wrote: >>> Hi, >>> >>> I don't see any SSL configuration option in Dovecot to disable >>> "Client-initiated secure renegotiation". >>> >>> It is advised to disable it as it can

On 09/03/16 10:44, Florent B wrote: > Hi, > > I don't see any SSL configuration option in Dovecot to disable > "Client-initiated secure renegotiation". > > It is advised to disable it as it can cause DDoS (CVE-2011-1473). > > Is it possible to have this possibility through an SSL option or other ? > > Thank you. > > Florent ssl_protocols = !SSLv3

Hi all, i read about the TLS-RENEGOTIATION vulnerability: http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html http://www.sslshopper.com/article-ssl-and-tls-renegotiation-vulnerability-discovered.html www.phonefactor.com/sslgapdocs/Renegotiating_TLS.pdf Does the Asterisk 1.6/1.8 SIP/TLS implementation suffer from the TLS Renegotiation vulnerability or the

Hello, I don't know who will read this message, but I found this thread: https://www.mail-archive.com/search?l=dovecot at dovecot.org&q=subject:%22Dovecot+2.3.0+TLS%22&o=newest And I'm expected the same issue, I will try to explain to you (english is not my native language, sorry) Since Buster update, so Dovecot update too, I'm not able to connect to my mail server from my

>>>>>>> facing [ no shared cipher ] error with EC private keys. >>>>>> the client connecting to your instance has to support ecdsa >>>>>> >>>>>> >>>>> It does - Thunderbird 60.0b10 (64-bit) >>>>> >>>>> [ security.ssl3.ecdhe_ecdsa_aes_256_gcm_sha384;true ] >>>>>

>>>>>> facing [ no shared cipher ] error with EC private keys. >>>>> the client connecting to your instance has to support ecdsa >>>>> >>>>> >>>> It does - Thunderbird 60.0b10 (64-bit) >>>> >>>> [ security.ssl3.ecdhe_ecdsa_aes_256_gcm_sha384;true ] >>>> >>>> It seems there is

What problem are you seeing? It uses the correct SSL certs when I connect. prompt> gnutls-cli --port 993 mail.nimmini.de Processed 149 CA certificate(s). Resolving 'mail.nimmini.de:993'... Connecting to '46.38.231.143:993'... - Certificate type: X.509 - Got a certificate list of 2 certificates. - Certificate[0] info: - subject `CN=nimmini.de', issuer `CN=Let's Encrypt

> On 30 July 2018 at 20:01 ????? <vtol at gmx.net> wrote: > > > > >>>> facing [ no shared cipher ] error with EC private keys. > >>> the client connecting to your instance has to support ecdsa > >>> > >>> > >> It does - Thunderbird 60.0b10 (64-bit) > >> > >> [

Hi, This is just a quick note to state that the recently reported SSL/TLS MITM attack[1] *does not* affect SSH. Like SSL/TLS, SSH supports key and parameter renegotiation, but it is not vulnerable because a session identifier is carried over from the first key exchange into all subsequent key exchanges. Technical details: In SSL, key exchanges and subsequent renegotiations are completely

Hi All, Sorry for disturbing you if the issues has been discussed earlier but I cannot find clear explanation of my problem. Tracing the tinc logs (a debug level) I have found that the MTU value of the connection is determined and chosen at the beginning of the tunnel setup. My question is following: is the MTU value renegotiated / rechecked after the tunnel is established? The question

Hi, I have a small question with sendmail and tls verification. The tls verify fails on our internal/external sendmail servers. For example: STARTTLS=server, relay=mx1.imt-systems.com [89.146.219.60], version=TLSv1/SSLv3, verify=FAIL, cipher=DHE-RSA-AES256-SHA, bits=256/256 STARTTLS=server, relay=acsinet12.imt-systems.com [89.146.219.42], version=TLSv1/SSLv3, verify=FAIL,

Hello, I am trying to replace a pointer argument of a call instruction with another pointer argument( new argument value for the call instruction). What is the best way to do it? I could not find any hint/guidance on the web or LLVM manual. Thanks, -- Abid M. Malik ****************************************************** "I have learned silence from the talkative, toleration from the

Dear All; Is there any work that discusses ​LLVM framework's short comings regarding auto vectorization and polyhedral optimizations? Regards, > -- Abid M. Malik ****************************************************** "I have learned silence from the talkative, toleration from the intolerant, and kindness from the unkind"---Gibran "Success is not for the chosen few, but

Hello, I was reading about secure Dialect negotiation to prevent man-in-middle to downgrade dialects & capabilities. _https://blogs.msdn.microsoft.com/openspecification/2012/06/28/smb3-secure-dialect-negotiation/_ I wanted to ask, is there any option to disable SMB2 to do dialect renegotiation as present in Windows8 clients, as they can control using RequireSecureNegotiate. -- Thanks Amit

Does it mean we can not dereference the Value variables? Value *val = some operand of an instruction; Value *val2= some operand of another instruction; I am trying to rewire the operand values of an instruction using: *val = *val2; It seems that this is not allowed. Thanks, -- Abid M. Malik ****************************************************** "I have learned silence from the

Andrew, Thanks for the pointers about looking into the ldap client libs. I think I've found a situation where tls connections to the AD server on port 389 have trouble. I've added the CA cert to ldap.conf, and to the ca_root_nss file on this system. First what works: 1. ldapsearch commands with -Z to force use of tls (configured in /usr/local/etc/ldap.conf) 2. ssl connections with

>>>> facing [ no shared cipher ] error with EC private keys. >>> the client connecting to your instance has to support ecdsa >>> >>> >> It does - Thunderbird 60.0b10 (64-bit) >> >> [ security.ssl3.ecdhe_ecdsa_aes_256_gcm_sha384;true ] >> >> It seems there is a difference between the private key (rsa vs. ecc -> >>

Hello, I am loop over the arguments of a call instruction : ----> for (Value *arg: c->args()){ errs() << *arg << "\n"; arg->print(llvm::errs(), false); errs()<<"\n"; } -----> How can I convert the arg for binary comparison(== etc.)? If I am correct, it is not a string. If the argument is "i32 1",

hi I want to use ECC(ellyptic curve cryptography) for SSL-connections but somehow dovecot doesn't like my ECC-certificates :( I tried to test using following scenario: machine: debian 6 (x64) dovecot 2.0.15-0~auto+21 ((f6a2c0e8bc03) from http://xi.rename-it.nl/debian openssl 1.0.0e-2 from testing (as the default 0.9.8o-4squeeze3 needs also the parameter -cipher ECCdraft for testing)