Re: SSLPolicy
Am 14.08.2017 um 17:14 schrieb Eric Covener : >> I hope this looks attractive to you. All bugs are mine. Let me know what you >> think. > > It looks neat. I think accessible doc will be key. yes. I was thinking of generating, but had no bright idea so far. > But for the sake of discussion, what will we do / what will > distributors do when say TLS1.3 or some esoteric part of it is only > available in some SSL toolkit releases? Well, the protocol defs do not exclude anything new. So TLS1.3 will just be "on" where available. > It seems like over time there are a lot of confusion with compile-time > vs. runtime openssl, forks, etc that either push towards "modern" > being ambiguous for a user or to have lots of different permutations > defined. That is rather the description of the state SSL configs is in now, is it not? Apart from the few who really know everyone copies sth from somewhere. And they can continue to do so. We take nothing away. We just offer them, hopefully, an easier way to define what they like. Plus some predefined policies for people that just want to use sth we offer. The rate of change should be very low, I think. If a Mom&Pop server goes https: it is just a bit easier to make it work with modern browsers. > > -- > Eric Covener > cove...@gmail.com
Re: SSLPolicy
> I hope this looks attractive to you. All bugs are mine. Let me know what you > think. It looks neat. I think accessible doc will be key. But for the sake of discussion, what will we do / what will distributors do when say TLS1.3 or some esoteric part of it is only available in some SSL toolkit releases? It seems like over time there are a lot of confusion with compile-time vs. runtime openssl, forks, etc that either push towards "modern" being ambiguous for a user or to have lots of different permutations defined. -- Eric Covener cove...@gmail.com
SSLPolicy
Here is my proposal for more semantic sugar. It defines 3 new SSL* config directives: - to define a set of SSL* directives under a name - SSLPolicy merge the non-proxy parts of the policy into the current server config. local directives will override - SSLProxyPolicymerge the proxy parts of the policy into the current server config. local directives will override There are atm 3 predefined policies: modern, intermediate, old (from https://wiki.mozilla.org/Security/Server_Side_TLS) In order to apply them on TLS connections to the client, you configure SSLPolicy modern in your server config or in a specific vhost. To affect the backend proxy connections, you may add: SSLProxyPolicy intermediate All settings beside a policy apply as usual. They do override policy values. The order does not matter: SSLPolicy modern SSLProtocol SSLv3 is the same as SSLProtocol SSLv3 SSLPolicy modern When you define multiple policy uses in the same server, they are merged in the reverse order (or override each other in document order, e.g. last one wins): SSLPolicy modern SSLPolicy intermediate will give you "intermediate" security settings, while SSLPolicy intermediate SSLPolicy modern will give you "modern" ones. You can override policies, so if someone wants to "hotfix" a policy, she can write: SSLPolicy modern SSLCipherSuite "VERYHOTNEWONE" or you expand a policy: SSLPolicy modern SSLEngine on I hope this looks attractive to you. All bugs are mine. Let me know what you think. Cheers, -Stefan ssl_policy_v2.diff Description: Binary data
Re: svn commit: r1804671 - /httpd/httpd/trunk/modules/md/mod_md_config.c
Already requested in Git issue #17 :
On Windows: A script to sent an email, kill zombie processes (needed
now on Win), copy e.g. cert's to mail servers etc.
Btw.
There there is at moment no restart in mod-md code for Windows, maybe
a dev has a solution (Maybe Bill) ?
In mod_md_os.c now:
#ifdef WIN32
apr_status_t md_server_graceful(apr_pool_t *p, server_rec *s)
{
return APR_ENOTIMPL;
}
#else
apr_status_t md_server_graceful(apr_pool_t *p, server_rec *s)
{
apr_status_t rv;
rv = (kill(getppid(), AP_SIG_GRACEFUL) < 0)? APR_ENOTIMPL :
APR_SUCCESS;
ap_log_error(APLOG_MARK, APLOG_TRACE1, errno, NULL, "sent signal
to parent");
return rv;
}
endif
On Monday 14/08/2017 at 13:07, Greg Stein wrote:
Oh, I don't know that Infra has any specific request on the
restart/update mechanism. I'd just say: build it how you think best.
What would work for Everybody should work just fine for us.
On Mon, Aug 14, 2017 at 2:09 AM, Stefan Eissing
wrote:
Thanks for the feedback and the crosspost. I think it would be great
to offer peeps
that already link serf into their server to avoid an additional
dependency.
Regarding Apache infrastructure use:
Would you prefer that the server gracefully restarts itself (when
needed, at a time
interval configured?) or is this something where you prefer outside
control anyway and
maybe a callable script that notifies/mails an admin?
-Stefan
Am 14.08.2017 um 07:43 schrieb Greg Stein :
[cc: serf]
> On Fri, Aug 11, 2017 at 3:41 AM, Stefan Eissing
wrote:
>...
> If you're looking at this anyway, how hard would it be for someone
knowledgeable to make a md_serf.c as alternative to md_curl.c? ^^
> Should be pretty easy, I think. Looking at serf_get.c will give
somebody an easy path to build the alternative:
http://svn.apache.org/repos/asf/serf/trunk/test/serf_get.c
> There is a lot of stuff in there that isn't applicable, so the core
should be quite small/easy. And it uses APR pools (and whatnot), so
the impedance should be very low.
> While I'm busy over in Infra-land, there are other Serf people here
and happy to help. I'll certainly throw in on some reviews, if/when I
see the commits.
> And from ASF/Infra side: we'd love to see this code hit a release
soon. We've been very hesitant to use LE in our deployments because
the httpd and puppet config/scripts are quite rough. It doesn't "Just
Work". This would go a long ways towards solving numerous
certificate-related issues for us.
Thanks,
-g
Re: svn commit: r1804671 - /httpd/httpd/trunk/modules/md/mod_md_config.c
Oh, I don't know that Infra has any specific request on the restart/update mechanism. I'd just say: build it how you think best. What would work for Everybody should work just fine for us. On Mon, Aug 14, 2017 at 2:09 AM, Stefan Eissing < stefan.eiss...@greenbytes.de> wrote: > Thanks for the feedback and the crosspost. I think it would be great to > offer peeps > that already link serf into their server to avoid an additional dependency. > > Regarding Apache infrastructure use: > > Would you prefer that the server gracefully restarts itself (when needed, > at a time > interval configured?) or is this something where you prefer outside > control anyway and > maybe a callable script that notifies/mails an admin? > > -Stefan > > > Am 14.08.2017 um 07:43 schrieb Greg Stein : > > > > [cc: serf] > > > > On Fri, Aug 11, 2017 at 3:41 AM, Stefan Eissing < > stefan.eiss...@greenbytes.de> wrote: > > >... > > If you're looking at this anyway, how hard would it be for someone > knowledgeable to make a md_serf.c as alternative to md_curl.c? ^^ > > > > Should be pretty easy, I think. Looking at serf_get.c will give somebody > an easy path to build the alternative: > > http://svn.apache.org/repos/asf/serf/trunk/test/serf_get.c > > > > There is a lot of stuff in there that isn't applicable, so the core > should be quite small/easy. And it uses APR pools (and whatnot), so the > impedance should be very low. > > > > While I'm busy over in Infra-land, there are other Serf people here and > happy to help. I'll certainly throw in on some reviews, if/when I see the > commits. > > > > And from ASF/Infra side: we'd love to see this code hit a release soon. > We've been very hesitant to use LE in our deployments because the httpd and > puppet config/scripts are quite rough. It doesn't "Just Work". This would > go a long ways towards solving numerous certificate-related issues for us. > > > > Thanks, > > -g > > > >
Re: svn commit: r1804671 - /httpd/httpd/trunk/modules/md/mod_md_config.c
Thanks for the feedback and the crosspost. I think it would be great to offer peeps that already link serf into their server to avoid an additional dependency. Regarding Apache infrastructure use: Would you prefer that the server gracefully restarts itself (when needed, at a time interval configured?) or is this something where you prefer outside control anyway and maybe a callable script that notifies/mails an admin? -Stefan > Am 14.08.2017 um 07:43 schrieb Greg Stein : > > [cc: serf] > > On Fri, Aug 11, 2017 at 3:41 AM, Stefan Eissing > wrote: > >... > If you're looking at this anyway, how hard would it be for someone > knowledgeable to make a md_serf.c as alternative to md_curl.c? ^^ > > Should be pretty easy, I think. Looking at serf_get.c will give somebody an > easy path to build the alternative: > http://svn.apache.org/repos/asf/serf/trunk/test/serf_get.c > > There is a lot of stuff in there that isn't applicable, so the core should be > quite small/easy. And it uses APR pools (and whatnot), so the impedance > should be very low. > > While I'm busy over in Infra-land, there are other Serf people here and happy > to help. I'll certainly throw in on some reviews, if/when I see the commits. > > And from ASF/Infra side: we'd love to see this code hit a release soon. We've > been very hesitant to use LE in our deployments because the httpd and puppet > config/scripts are quite rough. It doesn't "Just Work". This would go a long > ways towards solving numerous certificate-related issues for us. > > Thanks, > -g >
