issue with ssl_ciphers not being respected

[Scott Larson]

     Something else must be going on here. Looking at your ssl_cipher
string, you're opening with a rough declaration of specific ciphers you'll
support, none of which should pull in RC4. It's specific enough in fact
that your subsequent excluded ciphers don't even come into play. To test
this I switched in my old RSA cert, rebuilt 1.7.6 against OpenSSL 1.0.1j,
and hit it with `nmap --script ssl-enum-ciphers www.ossuary.net` and the
results with your exact string and removing the exclusions returned
identical supported options from the server on both runs, none of which
were RC4.
     As for the location, in my tests this was defined within the server{}
block. Without seeing your entire config, if you witness RC4 as truly being
offered my guesses would be that it's declared in a place which is being
ignored so nginx falls back to the default value, there is a second less
strict declaration somewhere (maybe in an include) overriding it, or there
is a proxy in front which is doing the actual termination.




*__________________Scott LarsonSystems AdministratorWiredrive/LA310 823
8238 ext. 1106310 943 2078 faxwww.wiredrive.com
<http://www.wiredrive.com/>www.twitter.com/wiredrive
<http://www.twitter.com/wiredrive>www.facebook.com/wiredrive
<http://www.wiredrive.com/facebook>*

On Thu, Oct 16, 2014 at 2:03 PM, Jessica Litwin <jessica at litw.in> wrote:

> I can do this, but I guess my whole question was does this mean exclusion
> bits are broken?
>      I'm personally partial to just outright declaring my supported
> ciphers rather than using the exclusion bits. My personal server is
> aggressively strict, the setup for our production gear is much less so.
> Either way it allows me to know exactly what's available to clients.
>
> For lunatics with DSA keys and LibreSSL:
>
>      ssl_ciphers
> ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256;
>
> For more rational people with RSA keys and OpenSSL:
>
>      ssl_ciphers
> ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:DES-CBC3-SHA;
>
>
>
>
> *__________________Scott LarsonSystems AdministratorWiredrive/LA310 823
> 8238 ext. 1106310 943 2078 faxwww.wiredrive.com
> <http://www.wiredrive.com/>www.twitter.com/wiredrive
> <http://www.twitter.com/wiredrive>www.facebook.com/wiredrive
> <http://www.wiredrive.com/facebook>*
>
> On Thu, Oct 16, 2014 at 1:28 PM, Jessica Litwin <jessica at litw.in> wrote:
>
>> I'm sure. I'm very, very sure the correct site is being tested.
>>
>> On Thu, Oct 16, 2014 at 4:23 PM, mex <nginx-forum at nginx.us> wrote:
>>
>>> hi,
>>>
>>> > >
>>> > > - make sure you are testing correct server.
>>> > >
>>>
>>>
>>> i'd suggest to configure an additional access/error-log
>>> in that server {}  -  block, to be 100% sure.
>>>
>>>
>>> regards,
>>>
>>>
>>> mex
>>>
>>> Posted at Nginx Forum:
>>> http://forum.nginx.org/read.php?2,254028,254077#msg-254077
>>>
>>> _______________________________________________
>>> nginx mailing list
>>> nginx at nginx.org
>>> http://mailman.nginx.org/mailman/listinfo/nginx
>>>
>>
>>
>>
>> --
>> Jessica K. Litwin
>> jessicalitwin.com
>> twitter: press5
>> aim: press5key
>> skype: dr_jkl
>>
>> _______________________________________________
>> nginx mailing list
>> nginx at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx
>>
>
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20141016/a6475c86/attachment.html>