search for: renegotiate

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.

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

...or other ? >>> >>> Thank you. >>> >>> Florent >> ssl_protocols = !SSLv3 !SSLv2 >> >> Is that enough? > > I'm afraid not. I've got SSLv2 and SSLv3 disabled and with `openssl > s_client -connect $host:993` I still can successfully renegotiate by > passing a single 'R'. Are you use good ssl_cipher_list (https://wiki.mozilla.org/Security/Server_Side_TLS)? My config ## Service options # 10-ssl ssl = yes ssl_cert = </etc/pki/tls/certs/.crt ssl_key = </etc/pki/tls/private/.key ssl_require_crl = no ssl_ca = </etc/pki/tls...

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

...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 !important;">Asterisk from 11.X branch is able to renegotiate an audio codec after a <span style="color: rgb(0, 0, 0); line-height: normal;">SIP call session has been established (INVITE and 200 OK)?</span></p><p style="line-height: 1.5; margin: 0px; font-family: 'Lucida Grande', 'Lucida Sans Unicode', sans-...

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

Using Asterisk-1.4.17, Zaptel-1.4.8, libpri-1.4.3 Upgraded this morning, now PRI channels are unstable as hell. After about 5 minutes all asterisk commands on the console refuse to respond, attached is the debug log right before and after the "lock-up", IT occurred between 9:18 and 9:20 AM at 9:20 I restarted asterisk. Box is debian w/ asterisk built from scratch. My setup is

...MITM) oblivious to the fact that the MITM has injected data. In SSH, the first key exchange generates a "session identifier" in addition to a key. This session identifier is used in the derivation of all future cipher and MAC keys (RFC4253 section 7.2). If an attacker tried the proxy and renegotiate SSL attack on SSH, the real client's session ID would not match that generated by the server, causing the derived keys to be different. The connection would terminate with a MAC error as soon as the first data was exchanged. (http://djm.net.au/2009/11/6/ssh-is-not-vulnerable-to-the-ssl-tls-mit...

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

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

...turbing 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 concerns the following observation. After successful connection everything is working correctly. Unfortunately since I am using tunnelling over GPRS media -for some time the quality of the connection is degraded. When it happens I am obse...

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

..._ok(dev); - if (err) - goto err; + ret = virtio_features_ok(dev); +exit: + return ret; +} + +static int virtio_dev_probe(struct device *_d) +{ + int err; + struct virtio_device *dev = dev_to_virtio(_d); + struct virtio_driver *drv = drv_to_virtio(dev->dev.driver); + u64 blocked_features; + bool renegotiate = true; + + /* We have a driver! */ + virtio_add_status(dev, VIRTIO_CONFIG_S_DRIVER); + + /* Store blocked features and attempt to negotiate features & probe. + * If the probe fails, we check if the driver has blocked any new features. + * If it has, we reset the device and try again with the...

Dear colleagues, experimenting with new amd64-based router we found strange re(4) behaviour when working in autoselect media mode: whenever promisc mode turned on, renegotiating occurs, leading to 3 to 45 (depending on STP settings on the switch) network unavailability. Moreover, some other re(4) setting changes seem to disturb link state unneededly (such as ifconfig re0 -vlanhwtag) The most

Hi Keir: [NET] front: Fix features on resume when csum is off When the netfront driver is resumed the features are renegotiated with the backend. However, I forgot take into account the status of the TX checksum setting. When TX checksum is disabled by the user, we cannot enable SG or TSO since both require checksum offload. This patch makes xennet check the checksum setting before renegotiating SG or TSO. This bug was...

...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 Kumar !!If you stumble, get back up. What happened yesterday, no longer matters. Today is another day to move closer to your GOAL!!

...es_ok(dev); > +exit: > + return ret; > +} > + > +static int virtio_dev_probe(struct device *_d) > +{ > + int err; > + struct virtio_device *dev = dev_to_virtio(_d); > + struct virtio_driver *drv = drv_to_virtio(dev->dev.driver); > + u64 blocked_features; > + bool renegotiate = true; > + > + /* We have a driver! */ > + virtio_add_status(dev, VIRTIO_CONFIG_S_DRIVER); > + > + /* Store blocked features and attempt to negotiate features & probe. > + * If the probe fails, we check if the driver has blocked any new features. > + * If it has, we rese...

...sh client doesn't try to re-establish the session for the ServerAlive messages to work. The shells remain blocked after the modem reboots, and after approximately 90*6 seconds, ssh aborts complaining of timeout with the remote server. I want to know if there is any way I can get ssh to try to renegotiate the active sessions to remote servers, without disconnecting them. Note: Please don't bother suggesting workarounds such as the use of screen, autossh, etc. I am looking for a specific answer about how to keep a session alive, or the impossibility of doing that. For example, autossh restarts...

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

...ever arrive at the server; this happens in about half of the phones- with no consistency as to which lose registration. It looks like the router is swallowing the messages, or there's some kind of NAT problem. Other clients at other sites are fine. The problem clears if the phone is rebooted (renegotiates a new nat path?) Any help warmly appreciated. John -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20111121/c6b6f7b1/attachment.htm>