On Tue, 26 May 2015 10:37:28 +0200
Stefan Eissing stefan.eiss...@greenbytes.de wrote:
Sorry, if this question has an obvious answer which I was unable to find:
where would I find a list of the changes that will be backported to the
2.4.13 release in order to see if a change has received
Current mod_ssl code tries to read embedded DH and ECC parameters only
from the first certificate file. Although this is documented
DH and ECDH parameters, however, are only read from the first
SSLCertificateFile directive, as they are applied independently of the
authentication algorithm
On 26 May 2015, at 10:37 AM, Stefan Eissing stefan.eiss...@greenbytes.de
wrote:
Sorry, if this question has an obvious answer which I was unable to find:
where would I find a list of the changes that will be backported to the
2.4.13 release in order to see if a change has received enough
On 26 May 2015, at 09:37, Reindl Harald h.rei...@thelounge.net wrote:
Am 26.05.2015 um 10:33 schrieb Rainer Jung:
Current mod_ssl code tries to read embedded DH and ECC parameters only from
the first certificate file. Although this is documented
DH and ECDH parameters, however, are only
Am 22.05.2015 um 18:35 schrieb Yann Ylavic:
On Fri, May 22, 2015 at 6:29 PM, Rainer Jung rainer.j...@kippdata.de wrote:
1) In other code I see
EC_KEY_free(ecdh);
after
EC_KEY *ecdh = EC_KEY_new_by_curve_name(...)
and using ecdh, e.g. in
SSL_CTX_set_tmp_ecdh(mctx-ssl_ctx, eckey);
Sorry, if this question has an obvious answer which I was unable to find: where
would I find a list of the changes that will be backported to the 2.4.13
release in order to see if a change has received enough votes?
Thanks.
//Stefan
green/bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone:
Am 26.05.2015 um 10:33 schrieb Rainer Jung:
Current mod_ssl code tries to read embedded DH and ECC parameters only
from the first certificate file. Although this is documented
DH and ECDH parameters, however, are only read from the first
SSLCertificateFile directive, as they are applied
Oups, several simultaneous responses...
Hope too much information does not kill the information :p
On Tue, May 26, 2015 at 11:03 AM, Yann Ylavic ylavic@gmail.com wrote:
Hi Stefan,
On Tue, May 26, 2015 at 10:37 AM, Stefan Eissing
stefan.eiss...@greenbytes.de wrote:
Sorry, if this question
Hi Stefan,
Am 26.05.2015 um 10:37 schrieb Stefan Eissing:
Sorry, if this question has an obvious answer which I was unable to find: where
would I find a list of the changes that will be backported to the 2.4.13
release in order to see if a change has received enough votes?
The backports
Hi Stefan,
On Tue, May 26, 2015 at 10:37 AM, Stefan Eissing
stefan.eiss...@greenbytes.de wrote:
Sorry, if this question has an obvious answer which I was unable to find:
where would I find a list of the changes that will be backported to the
2.4.13 release in order to see if a change has
Thanks for the many answers!
Now, can I win someone over to propose backporting the mod_ssl ALPN changes? I
have prepared something:
* mod_ssl: add ALPN support by allowing other modules to register callbacks
for negotiation of the application layer protocol.
trunk patch:
On Tue, May 26, 2015 at 12:30 PM, Stefan Eissing
stefan.eiss...@greenbytes.de wrote:
Now, can I win someone over to propose backporting the mod_ssl ALPN changes?
[to committers]
Who goes?
It would be funny to have 4 proposals though... :)
Am 26.05.2015 um 11:00 schrieb Tim Bannister:
On 26 May 2015, at 09:37, Reindl Harald h.rei...@thelounge.net wrote:
Am 26.05.2015 um 10:33 schrieb Rainer Jung:
Current mod_ssl code tries to read embedded DH and ECC parameters only from the
first certificate file. Although this is documented
Flattery! (I experience I am not immune to this…)
Thanks for all the replies! I am currently making a patch that contains all the
ALPN changes from trunk and works in 2.4. Hope that someone then can include
this as proposal in the 2.4.13 STATUS. May it find votes!
Back soonish...
Am
Am 26.05.2015 um 11:07 schrieb Yann Ylavic:
Oups, several simultaneous responses...
That shows how much we like him (his work) :)
On Tue, May 26, 2015 at 2:03 PM, Yann Ylavic ylavic@gmail.com wrote:
On Sat, Apr 25, 2015 at 11:46 AM, kbr...@apache.org wrote:
Author: kbrand
Date: Sat Apr 25 09:46:09 2015
New Revision: 1676004
URL: http://svn.apache.org/r1676004
Log:
Remove NPN support and focus on ALPN (RFC 7301)
Good catch.
Was done in r1676004 and reverted in r1681746. The latter slipped through my
NPN/ALPN sieve.
So, basically the html changes should be removed from the patch.
//Stefan
Am 26.05.2015 um 14:03 schrieb Yann Ylavic ylavic@gmail.com:
On Sat, Apr 25, 2015 at 11:46 AM,
On Tue, May 26, 2015 at 12:30 PM, Stefan Eissing
stefan.eiss...@greenbytes.de wrote:
Thanks for the many answers!
Now, can I win someone over to propose backporting the mod_ssl ALPN changes?
Proposed in r1681749 by also including r1681741 (CHANGES entry) and
r1681746 (revert on HTML docs
Thanks Yann!
Am 26.05.2015 um 14:26 schrieb Yann Ylavic ylavic@gmail.com:
On Tue, May 26, 2015 at 12:30 PM, Stefan Eissing
stefan.eiss...@greenbytes.de wrote:
Thanks for the many answers!
Now, can I win someone over to propose backporting the mod_ssl ALPN changes?
Proposed in
On Tue, May 26, 2015 at 2:26 PM, Yann Ylavic ylavic@gmail.com wrote:
On Tue, May 26, 2015 at 12:30 PM, Stefan Eissing
stefan.eiss...@greenbytes.de wrote:
Thanks for the many answers!
Now, can I win someone over to propose backporting the mod_ssl ALPN changes?
Proposed in r1681749 by
Hi,
currently the port for fcgi:// protocol defaults to 8000. Is there any
reason why we use this port number as a default? Also, I think this
default port number is not documented anywhere.
I'm asking, because php-fpm uses port 9000 by default. I know that these
ports are not standardized
On Sat, Apr 25, 2015 at 11:46 AM, kbr...@apache.org wrote:
Author: kbrand
Date: Sat Apr 25 09:46:09 2015
New Revision: 1676004
URL: http://svn.apache.org/r1676004
Log:
Remove NPN support and focus on ALPN (RFC 7301)
[]
Modified:
httpd/httpd/trunk/docs/manual/mod/directives.html.en
On Tue, May 26, 2015 at 10:45 AM, Yann Ylavic ylavic@gmail.com wrote:
On Tue, May 26, 2015 at 5:29 PM, Andy Wang aw...@ptc.com wrote:
# SSL Cipher Suite:
# List the ciphers that the client is permitted to negotiate.
# See the mod_ssl documentation for a complete list.
On Tue, May 26, 2015 at 5:29 PM, Andy Wang aw...@ptc.com wrote:
---
# SSL Cipher Suite:
# List the ciphers that the client is permitted to negotiate.
# See the mod_ssl documentation for a complete list.
SSLCipherSuite HIGH:MEDIUM:!MD5:!RC4
SSLProxyCipherSuite HIGH:MEDIUM:!MD5:!RC4
How about asking IANA to assign a port?
--
Tim Bannister – is...@c8h10n4o2.org.uk
---
# SSL Cipher Suite:
# List the ciphers that the client is permitted to negotiate.
# See the mod_ssl documentation for a complete list.
SSLCipherSuite HIGH:MEDIUM:!MD5:!RC4
SSLProxyCipherSuite HIGH:MEDIUM:!MD5:!RC4
!aNULL isn't needed?
Folks,
Did a scan through a fair bit of our code. mod_digest is not the only place;
e.g. in basic auth; we are also
not as careful in all cases as we could be.
So I think that what is needed are two (or three) functions
- A fairly mundane (binary) timing safe compare that compares two
On 05/26/2015 11:25 AM, William A Rowe Jr wrote:
On Tue, May 26, 2015 at 10:45 AM, Yann Ylavic ylavic@gmail.com
mailto:ylavic@gmail.com wrote:
On Tue, May 26, 2015 at 5:29 PM, Andy Wang aw...@ptc.com
mailto:aw...@ptc.com wrote:
# SSL Cipher Suite:
# List
On 26 May 2015, at 17:22, Dirk-Willem van Gulik di...@webweaving.org wrote:
..
So I think that what is needed are two (or three) functions
...
- A string comparison function; where at least one string is is under
control of the attacker.
Now the issue here is that length is every easily
29 matches
Mail list logo
