similar to: SSL Ciphers

Hi All. In curl manual: --ciphers -> "(SSL) Specifies which ciphers to use in the connection. The list of ciphers must specify valid ciphers. Read up on SSL cipher list details on this URL:http://www.openssl.org/docs/apps/ciphers.html" In openssl: http://www.openssl.org/docs/apps/ciphers.html#CIPHER_SUITE_NAMES there are names such as "SSL_RSA_WITH_RC4_128_SHA RC4-SHA" but

Am 19.10.2016 um 00:58 schrieb Gordon Messmer <gordon.messmer at gmail.com>: > On 10/18/2016 03:28 PM, Clint Dilks wrote: >> So first >> question is are people generally modifying the list of ciphers supported by >> the ssh client and sshd? > > I suspect that "generally" people are not. I do, because I can, and so that I can offer at least some advice

I'm trying to get nessus setup for doing some internal security checking. I installed the ports for nessus and nessus-plugins, and everything worked as expected. I then registered for the full feed of plugins, which got me up to over 10,000 plugins. I restarted nessus, and it didn't work at all. I am running without X11, so I'm doing batch runs. I already have nmap installed, so I

Thanks for the replies. The tool that we used for testing the security vulnerability is "Nessus". I have glibc version 2.17-78.el7, I saw that CVE-2015-0235 (Ghost) is fixed in this version and I want to apply patch for the vulnerbailities CVE-2015-1472 & CVE-2015-1473. Can you please help me in finding the right version that has fixes for these? Thanks On Sat, Apr 25, 2015 at

I've set up a list of ciphers that excludes SSLv2 ciphers (and other weak ones) in the hope of preventing SSLv2 connections: ssl_cipher_list = TLSv1+HIGH : !SSLv2 : RC4+MEDIUM : !aNULL : !eNULL : !3DES : @STRENGTH However, this doesn't prevent the SSLv2 connection being allowed as our Nessus scans show and I'm tasked with trying to plug that "hole". I see Dovecot2 had

Hi all, this is a patch to make Ciphers, MACs and KexAlgorithms available in Match blocks. Now I can reach a -current machine with some Android terminal app without changing the default ciphers for all clients: Match Address 192.168.1.2 Ciphers aes128-cbc MACs hmac-sha1 KexAlgorithms diffie-hellman-group-exchange-sha1 Index: servconf.c

Hi, I am trying to confirm that openssh transmissions do not use any kind of SSLv2 ciphers. I have glanced through the code briefly, and I did not find any indication that any openssl ciphers are even being used (it appears that openssl is used primarily for RSA key generation and select other things). So openssh uses its own built-in ciphers instead, right? Thanks for the assistance, Steven

I see that: SSH uses the following ciphers for encryption: Cipher SSH1 SSH2 DES yes no 3DES yes yes IDEA yes no Blowfish yes yes Twofish no yes Arcfour no yes Cast128-cbc no yes Two ques re: sshd: 1) Using openssh, how do I configure which

On 17.4.2019 23.00, Kostya Vasilyev via dovecot wrote: > I'm not Aki but hope you don't mind... > > On Wed, Apr 17, 2019, at 10:42 PM, TG Servers via dovecot wrote: >> Hi, >> >> MariaDB documentation says it accepts OpenSSL cipher strings in its >> ssl_cipher parameters like ssl_cipher="TLSv1.2". >> This is also mentioned when creating or

Hi, In a recent security review some systems I manage were flagged due to supporting "weak" ciphers, specifically the ones listed below. So first question is are people generally modifying the list of ciphers supported by the ssh client and sshd? On CentOS 6 currently it looks like if I remove all the ciphers they are concerned about then I am left with Ciphers

Why are legacy MACs (like md5-96), and legacy Ciphers (anything in cbc-mode, arcfour*(?)) enabled by default? My proposal would be to change the defaults for ssh_config and sshd_config to contain: MACs hmac-sha2-256,hmac-sha2-512,hmac-sha1 Ciphers aes128-ctr,aes192-ctr,aes256-ctr ...removing md5, truncated versions of sha1, umac64 (for which I can find barely any review), any cipher in cbc

Hi Ryan, I am not authenticating to any Windows server, I just have the samba server itself set up with 3 users who an login. ...Paul Ryan Frantz wrote: >Paul, > >Are you using a Windows PDC or ADS to authenticate your Samba shares? >If so, the problem would not be with Samba, but with the authenticating >server. > >Ryan > >-----Original Message----- >From:

Once upon a time, Erik Laxdal <elaxdal at ece.uvic.ca> said: > The supported KexAlgorithms, Ciphers, and MACs are generally listed > in the sshd_config man page. So 'man sshd_config' then look for the > section of the item of interest. Note that the man page does not always match the actual compiled binary (the build process does not update the man page to match

Recently, i scanned my samba4.1 server by Nessus (a vulnerability scanner tool - http://www.tenable.com/products/nessus) Nessus says that Samba4 is vulnerable to "LDAP NULL BASE Search Access" as "The remote LDAP server may disclose sensitive information." Further it says that - The remote LDAP server supports search requests with a null, or empty, base object. This allows

Can you use both ssl_protocols *and* ssl_cipher_list in the same config (in a way that's sane)? ssl_protocols (>= 2.1) and ssl_cipher_list co-exist, or are they mutually exclusive? I have a Dovecot 2.2.13 system, and I tried setting: I also tried things like ssl_cipher_list = HIGH or ssl_cipher_list = HIGH:!MEDIUM:!LOW however, doing this seems to make v3 still work unless I

On 12/2/2014 1:32 AM, Reindl Harald wrote: > > Am 02.12.2014 um 06:44 schrieb Will Yardley: >> On Mon, Dec 01, 2014 at 09:27:48PM -0800, Darren Pilgrim wrote: >>> On 12/1/2014 4:43 PM, Will Yardley wrote: >>>> Can you use both ssl_protocols *and* ssl_cipher_list in the same config >>>> (in a way that's sane)? >>> >>>> Is there a

Hi folks, At least several endpoints (soft phone and desk phones) are supporting various 256 bit ciphers for SRTP these days. I *believe* libsrtp has been updated to allow this, and that only the code in Asterisk has not been been updated to allow these stronger ciphers. Would anyone with the know-how be willing/able to submit a patch ? Thank you, Kevin Long

Hello all, I’m running Shorewall 2.2.1 on linux kernel 2.6.10 with iptables 1.2.11. I recently ran a nessus scan of my firewall from a machine outside of the firewall and the nessus report told me that there are some ports open that I did not specify to be open. The ports are 32772/udp, 123/udp, 111/tcp, 32772/udp, and 53/udp. Why are these ports open when I did NOT specify them to be open

Hi, I am running the below servers on Red Hat Enterprise Linux release 8.7 (Ootpa). The details are as follows. # rpm -qa | grep openssh openssh-8.0p1-16.el8.x86_64 openssh-askpass-8.0p1-16.el8.x86_64 openssh-server-8.0p1-16.el8.x86_64 openssh-clients-8.0p1-16.el8.x86_64 # cat /etc/redhat-release Red Hat Enterprise Linux release 8.7 (Ootpa) # How do I enable strong KexAlgorithms, Ciphers and