search for: sweet32

...he authentication protocol used in tinc 1.0, which allows a remote attacker to establish an authenticated connection with a node in the VPN, and send messages one-way. In tinc 1.0.29 and earlier, this is unfortunately trivial to exploit. In tinc 1.0.30 to 1.0.34, the mitigations implemented for the Sweet32 attack also make this attack much harder, but in principle still possible. This is fixed in tinc 1.0.35. The second issue allows a man-in-the-middle that has intercepted the TCP connection between two nodes, to potentially force one of the nodes to start sending unencrypted UDP packets. This is al...

...he authentication protocol used in tinc 1.0, which allows a remote attacker to establish an authenticated connection with a node in the VPN, and send messages one-way. In tinc 1.0.29 and earlier, this is unfortunately trivial to exploit. In tinc 1.0.30 to 1.0.34, the mitigations implemented for the Sweet32 attack also make this attack much harder, but in principle still possible. This is fixed in tinc 1.0.35. The second issue allows a man-in-the-middle that has intercepted the TCP connection between two nodes, to potentially force one of the nodes to start sending unencrypted UDP packets. This is al...

With pleasure we announce the release of tinc version 1.0.30. Here is a summary of the changes: * Fix troubles connecting to some HTTP proxies. * Add mitigations for the Sweet32 attack when using a 64-bit block cipher. * Use AES256 and SHA256 as the default encryption and digest algorithms. Please note that this version of tinc requires all nodes in the VPN to be linked with a version of OpenSSL or LibreSSL that supports the AES256 and SHA256 algorithms. While any reaso...

With pleasure we announce the release of tinc version 1.0.30. Here is a summary of the changes: * Fix troubles connecting to some HTTP proxies. * Add mitigations for the Sweet32 attack when using a 64-bit block cipher. * Use AES256 and SHA256 as the default encryption and digest algorithms. Please note that this version of tinc requires all nodes in the VPN to be linked with a version of OpenSSL or LibreSSL that supports the AES256 and SHA256 algorithms. While any reaso...

...ncludes a number of changes that may affect existing configurations: * This release removes server support for the SSH v.1 protocol. * ssh(1): Remove 3des-cbc from the client's default proposal. 64-bit block ciphers are not safe in 2016 and we don't want to wait until attacks like SWEET32 are extended to SSH. As 3des-cbc was the only mandatory cipher in the SSH RFCs, this may cause problems connecting to older devices using the default configuration, but it's highly likely that such devices already need explicit configuration for key exchange and hostkey algorithms a...

...ncludes a number of changes that may affect existing configurations: * This release removes server support for the SSH v.1 protocol. * ssh(1): Remove 3des-cbc from the client's default proposal. 64-bit block ciphers are not safe in 2016 and we don't want to wait until attacks like SWEET32 are extended to SSH. As 3des-cbc was the only mandatory cipher in the SSH RFCs, this may cause problems connecting to older devices using the default configuration, but it's highly likely that such devices already need explicit configuration for key exchange and hostkey algorithms a...

...ncludes a number of changes that may affect existing configurations: * This release removes server support for the SSH v.1 protocol. * ssh(1): Remove 3des-cbc from the client's default proposal. 64-bit block ciphers are not safe in 2016 and we don't want to wait until attacks like SWEET32 are extended to SSH. As 3des-cbc was the only mandatory cipher in the SSH RFCs, this may cause problems connecting to older devices using the default configuration, but it's highly likely that such devices already need explicit configuration for key exchange and hostkey algorithms a...

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