nginx Digest, Vol 9, Issue 2

Lorin Halpert alystair at gmail.com
Thu Jul 1 12:51:41 MSD 2010 

Ok, on further observation this is a Chrome error and not an Nginx error.
There is no real difference between my gif and yours, only happened to
forget to load mine which is why it displayed correctly in the specific
block (it was actually empty!). The bug renders the background with 1 less
brightness on all channels, so #FFFFFF becomes #FEFEFE and #443631
becomes #433530, etc. Attached a screenshot even though it's really not your
problem anymore. I'll report be reporting this to the Chromium developers,
you can rest easy about this.

Now I'm curious to know what color #256 would render as, probably something
odd from outside the buffer :)

On Thu, Jul 1, 2010 at 4:00 AM, <nginx-request at nginx.org> wrote:

> Send nginx mailing list submissions to
>        nginx at nginx.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://nginx.org/mailman/listinfo/nginx
> or, via email, send a message with subject or body 'help' to
>        nginx-request at nginx.org
>
> You can reach the person managing the list at
>        nginx-owner at nginx.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of nginx digest..."
>
>
> Today's Topics:
>
>   1. Re: how to deny the SSL v2.0 handshake when SSL v2.0 is
>      disabled (Igor Sysoev)
>   2. Empty GIF generator not actually empty (Lorin Halpert)
>   3. Re: Empty GIF generator not actually empty (Igor Sysoev)
>   4. Re: Empty GIF generator not actually empty (Igor Sysoev)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 1 Jul 2010 09:26:10 +0400
> From: Igor Sysoev <igor at sysoev.ru>
> To: nginx at nginx.org
> Subject: Re: how to deny the SSL v2.0 handshake when SSL v2.0 is
>        disabled
> Message-ID: <20100701052610.GA36735 at rambler-co.ru>
> Content-Type: text/plain; charset=koi8-r
>
> On Wed, Jun 30, 2010 at 04:21:25PM -0400, Calomel Org wrote:
>
> > Is there any way to completely disable the SSL v2.0 handshake when SSL
> > v2.0 support is disabled in nginx.conf ?
> >
> > This is the SSL configuration used and only TLSv1 is enabled in
> > "ssl_protocols".
> >
> >   ## Nginx SSL (FIPS 140-2 experimental)
> >    ssl on;
> >    ssl_certificate /ssl_keys/host.org_ssl.crt;
> >    ssl_certificate_key /ssl_keys/host_ssl.key;
> >    ssl_ciphers
> DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:EDH-RSA-DES-CBC3-SHA:AES256-SHA:DES-CBC3-SHA:AES128-SHA;
> >    ssl_dhparam /ssl_keys/host_dh.pem;
> >    ssl_prefer_server_ciphers on;
> >    ssl_protocols TLSv1;
> >    ssl_session_cache shared:SSL:10m;
> >    ssl_session_timeout 5m;
> >
> > The reason this question has come up is SSL Labs has recently been in
> > the news promoting a tool to check the compliance of a SSL server. We
> > thought we would check our host and we ranked at the very top (93%) of
> > the "Recent Best-Rated". The testing site can be found here:
> >
> >   https://www.ssllabs.com/ssldb/index.html
> >
> > When we checked our server (https://calomel.org) with their tool it
> > reported "SSL 2.0+ Upgrade Support" was enabled. We used the OpenSSL
> > binary on the command line and found SSLv2 and SSLv3 are definitely
> > turned off as Nginx denied the use of these protocols. Only TLSv1 was
> > allowed.
> >
> > The problem is the SSLv2 upgrade support handshake is somehow accepted
> > according to SSL Labs. I am not sure how to verify this handshake
> > myself.
> >
> > According to SSL Labs "SSL 2.0+ Upgrade Support" means, "...the server
> > supports SSLv2 handshake, even though it may not support SSLv2 itself.
> > Essentially it's an optimization. Instead of a client first requesting
> > SSLv2 (with a SSLv2 handshake) and failing (if the server does not
> > support it), then having to request SSLv3 or better (with a SSLv3
> > handshake), the client can use the SSLv2 handshake to indicate support
> > for newer protocols." The full news group thread containing this quote
> > can be found at:
> >
> >
> http://sourceforge.net/mailarchive/forum.php?thread_name=20100629171623.43012oj4b2hgrzi8%40webmail.mxes.net&forum_name=ssllabs-discuss
> >
> > Lastly, in order for a server to be considered "FIPS 140-2 Compliant"
> > it must not respond to any SSLv2 or SSLv3 protocol requests. Only
> > TLSv1 (version 1.0 to 1.2) are accepted.
> >
> > We appreciate any help, suggestions or clarification.
>
> As I understand OpenSSL sources it disables SSL 2.0+ upgrade support,
> only if FIPS is enabled. If you built OpenSSL with FIPS support,
> then add in openssl.cnf:
>
> openssl_conf = openssl_options
>
> [ openssl_options ]
> alg_section = algs
>
> [ algs ]
> fips_mode = yes
>
>
> --
> Igor Sysoev
> http://sysoev.ru/en/
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 1 Jul 2010 01:48:31 -0400
> From: Lorin Halpert <alystair at gmail.com>
> To: nginx at nginx.org
> Subject: Empty GIF generator not actually empty
> Message-ID:
>        <AANLkTilLCj8oYeQKPiVmc0OFT0717hKVAhQkV2onVD4i at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Using the built-in generator changes the color of the background color
> under
> Chrome, yet using my own blank doesn't cause this. I've attached a "known
> good" blank created in Fireworks (same byte size) so it can replace the one
> in the nginx codebase. I am under windows with no development tools so I
> can't create a patch myself but I'm able to test a new binary to validate
> that it's fixed.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://nginx.org/pipermail/nginx/attachments/20100701/d0cf4e89/attachment-0001.html
> >
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: b.gif
> Type: image/gif
> Size: 43 bytes
> Desc: not available
> URL: <
> http://nginx.org/pipermail/nginx/attachments/20100701/d0cf4e89/attachment-0001.gif
> >
>
> ------------------------------
>
> Message: 3
> Date: Thu, 1 Jul 2010 10:23:14 +0400
> From: Igor Sysoev <igor at sysoev.ru>
> To: nginx at nginx.org
> Subject: Re: Empty GIF generator not actually empty
> Message-ID: <20100701062314.GE36735 at rambler-co.ru>
> Content-Type: text/plain; charset=koi8-r
>
> On Thu, Jul 01, 2010 at 01:48:31AM -0400, Lorin Halpert wrote:
>
> > Using the built-in generator changes the color of the background color
> under
> > Chrome, yet using my own blank doesn't cause this. I've attached a "known
> > good" blank created in Fireworks (same byte size) so it can replace the
> one
> > in the nginx codebase. I am under windows with no development tools so I
> > can't create a patch myself but I'm able to test a new binary to validate
> > that it's fixed.
>
> The current empty GIF has 2 colors: #0: black and #1 white.
> The white (#1) color is used as background and as transparent color.
>
> The suggested GIF has two colors: #0 gray (C0C0C0) and #1 black.
> The transparent color is #0 (gray). The background color is #256
> and there is no such color number in the GIF table. I'm not sure
> how browsers will handle this case. Probably they use just #1 color.
>
> However, I do not understand the issue. Could you show example on
> the web where built-in GIF changes background color ?
>
>
> --
> Igor Sysoev
> http://sysoev.ru/en/
>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 1 Jul 2010 10:24:50 +0400
> From: Igor Sysoev <igor at sysoev.ru>
> To: nginx at nginx.org
> Subject: Re: Empty GIF generator not actually empty
> Message-ID: <20100701062450.GF36735 at rambler-co.ru>
> Content-Type: text/plain; charset=koi8-r
>
> On Thu, Jul 01, 2010 at 10:23:14AM +0400, Igor Sysoev wrote:
>
> > On Thu, Jul 01, 2010 at 01:48:31AM -0400, Lorin Halpert wrote:
> >
> > > Using the built-in generator changes the color of the background color
> under
> > > Chrome, yet using my own blank doesn't cause this. I've attached a
> "known
> > > good" blank created in Fireworks (same byte size) so it can replace the
> one
> > > in the nginx codebase. I am under windows with no development tools so
> I
> > > can't create a patch myself but I'm able to test a new binary to
> validate
> > > that it's fixed.
> >
> > The current empty GIF has 2 colors: #0: black and #1 white.
> > The white (#1) color is used as background and as transparent color.
> >
> > The suggested GIF has two colors: #0 gray (C0C0C0) and #1 black.
> > The transparent color is #0 (gray). The background color is #256
>
> The background color is #255 ...
>
> > and there is no such color number in the GIF table. I'm not sure
> > how browsers will handle this case. Probably they use just #1 color.
> >
> > However, I do not understand the issue. Could you show example on
> > the web where built-in GIF changes background color ?
>
>
> --
> Igor Sysoev
> http://sysoev.ru/en/
>
>
>
> ------------------------------
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://nginx.org/mailman/listinfo/nginx
>
>
> End of nginx Digest, Vol 9, Issue 2
> ***********************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20100701/68cc49bf/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gif bug.png
Type: image/png
Size: 6045 bytes
Desc: not available
URL: <http://nginx.org/pipermail/nginx/attachments/20100701/68cc49bf/attachment-0001.png>

More information about the nginx mailing list