similar to: Secure Client-Initiated Renegotiation

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

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

In setting up my new mail server, I am getting the following in the logs: Oct 11 07:10:59 kumo dovecot[5704]: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=24.53.79.10, lip=172.26.12.90, *TLS handshaking: SSL_accept() syscall failed: Success*, session=<B9OokqCUD+UYNU8K> I have tried various ssl_protocols entries, but for now have defaulted back to

hai, As far as i know, no. Unless you are forceing all clients to use SSLv2 only (since that doesn't support renegotiation). Are you sure you want to disable it and not just prevent old clients from using the vulnerable renegotiation methods? If it's the last you'll need to upgrade to 2.8+ to get access to tls_disable_workarounds. you have 2 problems. - One is the vulnerable

>>>>>> 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

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925961 -------- Forwarded Message -------- Subject: segfault in libdovecot-storage at unknown circumstances Date: Fri, 29 Mar 2019 16:34:15 +0300 From: sergio <sergio+it at outerface.net> To: Debian Bug Tracking System <submit at bugs.debian.org> Package: dovecot-core Version: 1:2.3.4.1-1~bpo9+1 Severity: normal Yes, I know this is

>>>> 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 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

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 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)

Disclaimer: Yes, I know faxing over G711 is unreliable. :-) We're running Asterisk 1.0.9 which talks to a Audiocodes SIP Gateway. We're running Sipura SPA-2002's as ATA's and faxing within our own voice network is working. If we try and fax out to the world however, we're running into a problem. When the call connects and the modem tones begin to negotiate, our SIP/PSTN

I have several samba servers on Debian 10 all using : samba 2:4.9.5+dfsg-5+deb10u1 amd64 I use tls cafile, tls certfile and tls keyfile with certificates from Sectigo (https://cert-manager.com) And when checking my connexion from the samba server, or from outside, I've got "unable to verify the first certificate" even if tls_cafile is provided in smb.conf. What is wrong

We use Asterisk 14 to proxy calls between two servers, 10.0.0.192 to 10.0.0.228. But sometimes another of our servers becomes listed as a SIP agent, even though the server's IP address isn't part of our sip.conf, extensions.conf, nor any other config I know of. For example in the log snippet below, the source server experienced an SDP renegotiation in the middle of a call, and seemingly as

> This is just another user like anyone else in the office. No, its offcourse not .. Why do you think you binding user is failing ;-) So, on the bind fail. Did you set on the "binding" user, : account is trusted and cant not be delegated? Password can be changed and never expire need to be ticked also. Whats set on the Pfsence server in ldap.conf ? Is BASE and URI defined? As

https://bugzilla.mindrot.org/show_bug.cgi?id=3087 Bug ID: 3087 Summary: Ed448 support Product: Portable OpenSSH Version: 8.1p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: Miscellaneous Assignee: unassigned-bugs at mindrot.org

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

If I were guessing, based on some experience with certificate usage in other apps, concatenate your certificate and intermediate certificates into a single file which is then your "tls certfile" then point "tls cafile" to your issuers proper CA or just to your distro's CA bundle, e.g /etc/pki/tls/certs/ca-bundle.crt. Nick On 06/08/2020 16:36, MAS Jean-Louis via samba

<div style="font:14px/1.5 'Lucida Grande', '微软雅黑';color:#333;"><p style="line-height: 1.5; margin: 0px; font-family: 'Lucida Grande', 'Lucida Sans Unicode', sans-serif !important;">Hi All,</p><p style="line-height: 1.5; margin: 0px; font-family: 'Lucida Grande', 'Lucida Sans Unicode', sans-serif

Hello All, We have interesting issue. When application connect to PDC by port 389 (without ssl) everything works fine. When we try to use SSL by port 636 we have issue. ldapsearch -x -D "cn=user,ou=users,dc=dc,dc=local" -p 636 -h PDC -b "DC=dc,DC=local" -w pass output: ldap_result: Can't contact LDAP server (-1) ldapsearch -x -D