Re: mod_tls in 2.4.x - remove?
On 4/16/24 12:56, Stefan Eissing via dev wrote: mod_tls is experimental in 2.4.x. The rustls project, initially wanting to stay backward compatible to the v0.10.x API, has change its mind and no longer guarantees any stability in future versions. In fact, they have changed the API already, making mod_tls no longer viable. I personally do not have the time to chase after this. If no one else has interests (and I don't know of anyone using it - else, speak up), I propose to remove it from the 2.4.x branch again. Kind Regards, Stefan I am +1 for that, I have looked to arrange the testsuite to test mod_ssl instead mod_ssl via pytest in trunk (PR: https://github.com/apache/httpd/pull/433) so I would like to keep mod_tls in trunk if possible (but I am NOT planning to work on mod_tls for the moment). -- Cheers Jean-Frederic
mod_tls in 2.4.x - remove?
mod_tls is experimental in 2.4.x. The rustls project, initially wanting to stay backward compatible to the v0.10.x API, has change its mind and no longer guarantees any stability in future versions. In fact, they have changed the API already, making mod_tls no longer viable. I personally do not have the time to chase after this. If no one else has interests (and I don't know of anyone using it - else, speak up), I propose to remove it from the 2.4.x branch again. Kind Regards, Stefan
Re: Testing mod_tls
> Am 22.12.2021 um 08:27 schrieb Christophe JAILLET > : > > Le 20/12/2021 à 09:58, Stefan Eissing a écrit : >>> Am 19.12.2021 um 10:36 schrieb Christophe JAILLET >>> : >>> >>> Hi, >>> >>> I've been able to build mod_tls >>> >>> Basically, I've done: >>> >>> sudo apt install cargo >>> sudo apt install cbindgen >>> >>> git clone https://github.com/rustls/rustls-ffi.git git_rustls-ffi >>> sudo make install >>> >>> I have: >>> /usr/local/lib/libcrustls.a >>> /usr/local/lib/librustls.a >>> /usr/local/include/crustls.h >>> /usr/local/include/rustls.h >>> >>> >>> pytest is also (apparently correctly) installed. >>> pytest test/modules/http2 works fine. >>> >>> >>> However, when I 'pytest test/modules/tls', I get: >>> >>> Syntax error on line 31 of >>> XXX/svn_httpd_2.4.x/test/gen/apache/conf/modules.conf: Cannot load >>> XXX/httpd-2.4/modules/mod_tls.so into server: >>> XXX/httpd-2.4/modules/mod_tls.so: undefined symbol: fmaf >>> >>> >>> My understanding is that mod_tls is correctly compiled, but that there is a >>> missing library somewhere. >>> >>> Does it ring some bell to s.o.? >> The issue came up here: https://github.com/rustls/rustls-ffi/issues/133 > > Hi, > > Rebuilding with the following patch made the trick for me. > > You know all that much better than me, so I let you see if it should be > applied on trunk/2.4.x. > > CJ > > > Index: modules/tls/config2.m4 > === > --- modules/tls/config2.m4(révision 1896121) > +++ modules/tls/config2.m4(copie de travail) > @@ -141,7 +141,7 @@ > MOD_TLS_LINK_LIBS="-lrustls -framework Security -framework > Foundation" > ;; > *) > -MOD_TLS_LINK_LIBS="-lrustls" > +MOD_TLS_LINK_LIBS="-lrustls -lm" > ;; >esac ># The only symbol which needs to be exported is the module Please apply. I seems to work on travis for ubuntu focal without it. But that does not mean it's sufficient for all platforms.
Re: Testing mod_tls
Le 20/12/2021 à 09:58, Stefan Eissing a écrit : Am 19.12.2021 um 10:36 schrieb Christophe JAILLET : Hi, I've been able to build mod_tls Basically, I've done: sudo apt install cargo sudo apt install cbindgen git clone https://github.com/rustls/rustls-ffi.git git_rustls-ffi sudo make install I have: /usr/local/lib/libcrustls.a /usr/local/lib/librustls.a /usr/local/include/crustls.h /usr/local/include/rustls.h pytest is also (apparently correctly) installed. pytest test/modules/http2 works fine. However, when I 'pytest test/modules/tls', I get: Syntax error on line 31 of XXX/svn_httpd_2.4.x/test/gen/apache/conf/modules.conf: Cannot load XXX/httpd-2.4/modules/mod_tls.so into server: XXX/httpd-2.4/modules/mod_tls.so: undefined symbol: fmaf My understanding is that mod_tls is correctly compiled, but that there is a missing library somewhere. Does it ring some bell to s.o.? The issue came up here: https://github.com/rustls/rustls-ffi/issues/133 Hi, Rebuilding with the following patch made the trick for me. You know all that much better than me, so I let you see if it should be applied on trunk/2.4.x. CJ Index: modules/tls/config2.m4 === --- modules/tls/config2.m4 (révision 1896121) +++ modules/tls/config2.m4 (copie de travail) @@ -141,7 +141,7 @@ MOD_TLS_LINK_LIBS="-lrustls -framework Security -framework Foundation" ;; *) -MOD_TLS_LINK_LIBS="-lrustls" +MOD_TLS_LINK_LIBS="-lrustls -lm" ;; esac # The only symbol which needs to be exported is the module
Re: Testing mod_tls
Le 20/12/2021 à 09:58, Stefan Eissing a écrit : Am 19.12.2021 um 10:36 schrieb Christophe JAILLET : Hi, I've been able to build mod_tls Basically, I've done: sudo apt install cargo sudo apt install cbindgen git clone https://github.com/rustls/rustls-ffi.git git_rustls-ffi sudo make install I have: /usr/local/lib/libcrustls.a /usr/local/lib/librustls.a /usr/local/include/crustls.h /usr/local/include/rustls.h pytest is also (apparently correctly) installed. pytest test/modules/http2 works fine. However, when I 'pytest test/modules/tls', I get: Syntax error on line 31 of XXX/svn_httpd_2.4.x/test/gen/apache/conf/modules.conf: Cannot load XXX/httpd-2.4/modules/mod_tls.so into server: XXX/httpd-2.4/modules/mod_tls.so: undefined symbol: fmaf My understanding is that mod_tls is correctly compiled, but that there is a missing library somewhere. Does it ring some bell to s.o.? The issue came up here: https://github.com/rustls/rustls-ffi/issues/133 Hi Stefan, Thx for the pointer. CJ CJ
Re: Testing mod_tls
> Am 19.12.2021 um 10:36 schrieb Christophe JAILLET > : > > Hi, > > I've been able to build mod_tls > > Basically, I've done: > > sudo apt install cargo > sudo apt install cbindgen > > git clone https://github.com/rustls/rustls-ffi.git git_rustls-ffi > sudo make install > > I have: > /usr/local/lib/libcrustls.a > /usr/local/lib/librustls.a > /usr/local/include/crustls.h > /usr/local/include/rustls.h > > > pytest is also (apparently correctly) installed. > pytest test/modules/http2 works fine. > > > However, when I 'pytest test/modules/tls', I get: > > Syntax error on line 31 of > XXX/svn_httpd_2.4.x/test/gen/apache/conf/modules.conf: Cannot load > XXX/httpd-2.4/modules/mod_tls.so into server: > XXX/httpd-2.4/modules/mod_tls.so: undefined symbol: fmaf > > > My understanding is that mod_tls is correctly compiled, but that there is a > missing library somewhere. > > Does it ring some bell to s.o.? The issue came up here: https://github.com/rustls/rustls-ffi/issues/133 > > CJ >
Testing mod_tls
Hi, I've been able to build mod_tls Basically, I've done: sudo apt install cargo sudo apt install cbindgen git clone https://github.com/rustls/rustls-ffi.git git_rustls-ffi sudo make install I have: /usr/local/lib/libcrustls.a /usr/local/lib/librustls.a /usr/local/include/crustls.h /usr/local/include/rustls.h pytest is also (apparently correctly) installed. pytest test/modules/http2 works fine. However, when I 'pytest test/modules/tls', I get: Syntax error on line 31 of XXX/svn_httpd_2.4.x/test/gen/apache/conf/modules.conf: Cannot load XXX/httpd-2.4/modules/mod_tls.so into server: XXX/httpd-2.4/modules/mod_tls.so: undefined symbol: fmaf My understanding is that mod_tls is correctly compiled, but that there is a missing library somewhere. Does it ring some bell to s.o.? CJ
added mod_tls to trunk and CI
FYI: mod_tls is in trunk. A travis test image is added and runs the pytest suite in test/modules/tls. First success: https://app.travis-ci.com/github/apache/httpd/builds/242716933 The module builds via configure, if it finds a librustls present in the system. Building can explicitly be requested by the usual configure options. CMake or other build systems I have not touched, as I am unable to test those. Since this is experimental, it should not be a problem. Perhaps someone well versed in other platforms and interested in rustls may tackle this in the future. Missing is the manual page for the module which is on my TODO list. Otherwise, since this builds and runs against a 2.4.x as well, we are able to offer a "memory safe" TLS to anyone who desires. (quotation marks as the non Rust parts, written by me, are not). Cheers, Stefan
Re: mod_tls as experimental module?
> Am 27.11.2021 um 14:21 schrieb Greg Stein : > > On Fri, Nov 26, 2021 at 3:49 AM ste...@eissing.org wrote: > >... > Additionally, we need to clarify with ASF and ISRG if this needs some sort of > paperwork. Since the ISRG repository uses the Apache license, in my naive > world > view, this should be quite an informal process. But I do not really know. > > We have numerous copies of permissive-licensed code within our repositories, > and that is fine as long as no such code is "more restrictive than the ALv2". > Since the existing mod_tls is provided under ALv2, then no additional > paperwork should be required. We are merely using that code under the license > provided. > > The real question is whether the files to be imported into our repository > have headers that specify copyright held by others. For that, we need to get > the copyright owners' approval to replace that with our standard header. > https://www.apache.org/legal/src-headers.html > (if we want to change them; we could simply copy from upstream, or change if > the locus of development is our repository) Thanks Greg. I will talk to the ISRG about the header change. Cheers, Stefan > > There is likely some other page talking about permission to switch out the > copyright header, but I don't have that link handy. > > Cheers, > -g >
Re: mod_tls as experimental module?
On Fri, Nov 26, 2021 at 3:49 AM ste...@eissing.org wrote: >... > Additionally, we need to clarify with ASF and ISRG if this needs some sort > of > paperwork. Since the ISRG repository uses the Apache license, in my naive > world > view, this should be quite an informal process. But I do not really know. > We have numerous copies of permissive-licensed code within our repositories, and that is fine as long as no such code is "more restrictive than the ALv2". Since the existing mod_tls is provided under ALv2, then no additional paperwork should be required. We are merely using that code under the license provided. The real question is whether the files to be imported into our repository have headers that specify copyright held by others. For that, we need to get the copyright owners' approval to replace that with our standard header. https://www.apache.org/legal/src-headers.html (if we want to change them; we could simply copy from upstream, or change if the locus of development is our repository) There is likely some other page talking about permission to switch out the copyright header, but I don't have that link handy. Cheers, -g
Re: mod_tls as experimental module?
Thanks everyone for giving feedback. I summarise this as an overall positive response. I will start next week on bringing this over as an experimental module. Also make the test cases run on one of our travis instances. Additionally, we need to clarify with ASF and ISRG if this needs some sort of paperwork. Since the ISRG repository uses the Apache license, in my naive world view, this should be quite an informal process. But I do not really know. It would be great, if there is any formality here, for someone else to drive this. I have mixed roles here as the author, contractor for ISRG and httpd pmc member. Joe: any advice? Kind Regards, Stefan > Am 25.11.2021 um 19:43 schrieb Daniel Ferradal : > > For me it is a +1, > > I didn´t say anything because I am not knowledgeable enough. > > Stefan, if noone answers it is not because of lack of interest but > probably because you are several steps ahead :) > > El jue, 25 nov 2021 a las 11:26, Greg Stein () escribió: >> >> On Thu, Nov 25, 2021 at 3:42 AM ste...@eissing.org >> wrote: >>> ... >>> >>> In its development, the arrival of mod_tls has caused changes in our server >>> core. Not in any way related to Rust itself. But we added the capability to >>> have more than one SSL/TLS provider in our server. So people can use >>> whatever fits best for the parts they need it. >>> >>> Future improvements in this area would be done easiest, if mod_tls is a >>> module in our source base next to mod_ssl. API dependencies are managed >>> better if we release enhanced versions together. I see no benefit for >>> anyone involved in making it a separate Apache httpd subproject. It has a >>> home on github with all its infrastructure. >> >> >> +1 on including mod_tls (or mod_rustls) in our tree as experimental. That is >> *precisely* why we have the experimental label. Historically, the concept of >> "subproject" has been ... suboptimal, to put it nicely. >> >> The changes to the core can/should be made regardless of adoption of this >> module. >> >> Cheers, >> -g >> > > > -- > Daniel Ferradal > HTTPD Project > #httpd help at Libera.Chat
Re: mod_tls as experimental module?
For me it is a +1, I didn´t say anything because I am not knowledgeable enough. Stefan, if noone answers it is not because of lack of interest but probably because you are several steps ahead :) El jue, 25 nov 2021 a las 11:26, Greg Stein () escribió: > > On Thu, Nov 25, 2021 at 3:42 AM ste...@eissing.org wrote: > >... >> >> In its development, the arrival of mod_tls has caused changes in our server >> core. Not in any way related to Rust itself. But we added the capability to >> have more than one SSL/TLS provider in our server. So people can use >> whatever fits best for the parts they need it. >> >> Future improvements in this area would be done easiest, if mod_tls is a >> module in our source base next to mod_ssl. API dependencies are managed >> better if we release enhanced versions together. I see no benefit for anyone >> involved in making it a separate Apache httpd subproject. It has a home on >> github with all its infrastructure. > > > +1 on including mod_tls (or mod_rustls) in our tree as experimental. That is > *precisely* why we have the experimental label. Historically, the concept of > "subproject" has been ... suboptimal, to put it nicely. > > The changes to the core can/should be made regardless of adoption of this > module. > > Cheers, > -g > -- Daniel Ferradal HTTPD Project #httpd help at Libera.Chat
Re: mod_tls as experimental module?
On Thu, Nov 25, 2021 at 3:42 AM ste...@eissing.org wrote: >... > In its development, the arrival of mod_tls has caused changes in our > server core. Not in any way related to Rust itself. But we added the > capability to have more than one SSL/TLS provider in our server. So people > can use whatever fits best for the parts they need it. > > Future improvements in this area would be done easiest, if mod_tls is a > module in our source base next to mod_ssl. API dependencies are managed > better if we release enhanced versions together. I see no benefit for > anyone involved in making it a separate Apache httpd subproject. It has a > home on github with all its infrastructure. > +1 on including mod_tls (or mod_rustls) in our tree as experimental. That is *precisely* why we have the experimental label. Historically, the concept of "subproject" has been ... suboptimal, to put it nicely. The changes to the core can/should be made regardless of adoption of this module. Cheers, -g
Re: mod_tls as experimental module?
> Am 24.11.2021 um 12:42 schrieb Graham Leggett : > > On 18 Nov 2021, at 19:48, ste...@eissing.org wrote: > >> How would you feel about adding mod_tls >> (https://github.com/abetterinternet/mod_tls) as an experimental module to >> Apache httpd? > > Having more choice is excellent. > >> For people who have not followed that development: >> - it is a TLS 1.2/1.3 implementation based on rustls, >> https://github.com/rustls/rustls >> - the C API is rustls-ffi, found at https://github.com/rustls/rustls-ffi >> - it is itself written in C, linking all the Rust things from the rustls-ffi >> library >> - it does not bring any Rust into our code base >> - functionality wise, it is a clear subset of what mod_ssl offers via openssl >> (e.g. no client certificates now and not as tweakable - at least for now) > > Client certs is a must for me. I know that they’re political, but my clients > in finance don’t care. Understood. They might come in the future, if rustls exposes the necessary functionality. But mod_tls is not intended as a full replacement for everything mod_ssl offers. For example, rustls will never support FIPS (my understanding). >> - it can be co-loaded and co-used with mod_ssl on different ports or >> front-/backend roles >> - performance-wise, according to my plain vanilla tests, it is on par with >> mod_ssl >> >> The decision to offer it downstream is of course then made by the distros, >> as usual with experimental modules. And if and how it is then used rests >> with the users. It is an offered alternative for people. >> >> What would be the benefit to the project? >> - we offer people an alternative. If they feel the memory safety that Rust >> offers is important to them, they can do it with Apache httpd for the TLS >> stack. >> - we could see how people react to this and adapt our TLS offering >> accordingly. It being experimental, we remain free to change it. Or remove >> it again. >> >> Organizational Things: >> - the development was done by myself >> - the work was sponsored by the ISRG (https://www.abetterinternet.org), the >> org behind Let's Encrypt, as part of they "memory safety" initiative >> (https://www.memorysafety.org) >> >> >> Feedback appreciated, > > I lean towards adding it as an httpd subproject at this level: > > https://svn.apache.org/viewvc/httpd/ > > This frees you from all the complexity around experimental bits of httpd > compared to fully supported bits. > > This means that practically, it can be packaged through channels like EPEL > until it becomes stable, at which point the distros will pick it up. > > It also insulates us against external dependencies like rust. Languages wax > and wane, should a rust2 coming along, or another language called oxide > that’s better, we’re not left with aging code in our codebase. This is a > problem that APR solves for us for operating systems. In its development, the arrival of mod_tls has caused changes in our server core. Not in any way related to Rust itself. But we added the capability to have more than one SSL/TLS provider in our server. So people can use whatever fits best for the parts they need it. Future improvements in this area would be done easiest, if mod_tls is a module in our source base next to mod_ssl. API dependencies are managed better if we release enhanced versions together. I see no benefit for anyone involved in making it a separate Apache httpd subproject. It has a home on github with all its infrastructure. Kind Regards, Stefan > > Regards, > Graham > —
Re: mod_tls as experimental module?
Add it in :-) > On Nov 24, 2021, at 4:46 AM, ste...@eissing.org wrote: > > Coming back to this. Since there was no feedback on my post: are people > just too occupied/opposed/not interested? > > Curious, > Stefan > >> Am 18.11.2021 um 18:48 schrieb ste...@eissing.org: >> >> How would you feel about adding mod_tls >> (https://github.com/abetterinternet/mod_tls) as an experimental module to >> Apache httpd? >> >> For people who have not followed that development: >> - it is a TLS 1.2/1.3 implementation based on rustls, >> https://github.com/rustls/rustls >> - the C API is rustls-ffi, found at https://github.com/rustls/rustls-ffi >> - it is itself written in C, linking all the Rust things from the rustls-ffi >> library >> - it does not bring any Rust into our code base >> - functionality wise, it is a clear subset of what mod_ssl offers via openssl >> (e.g. no client certificates now and not as tweakable - at least for now) >> - it can be co-loaded and co-used with mod_ssl on different ports or >> front-/backend roles >> - performance-wise, according to my plain vanilla tests, it is on par with >> mod_ssl >> >> The decision to offer it downstream is of course then made by the distros, >> as usual with experimental modules. And if and how it is then used rests >> with the users. It is an offered alternative for people. >> >> What would be the benefit to the project? >> - we offer people an alternative. If they feel the memory safety that Rust >> offers is important to them, they can do it with Apache httpd for the TLS >> stack. >> - we could see how people react to this and adapt our TLS offering >> accordingly. It being experimental, we remain free to change it. Or remove >> it again. >> >> Organizational Things: >> - the development was done by myself >> - the work was sponsored by the ISRG (https://www.abetterinternet.org), the >> org behind Let's Encrypt, as part of they "memory safety" initiative >> (https://www.memorysafety.org) >> >> >> Feedback appreciated, >> >> Stefan >> >> PS. On a more personal note: >> The way this project turned out was a clean separation between C and Rust. >> The API offered by rustls-ffi is colored by Rust's immutability/borrowed >> memory concepts, but there is nothing Rust special the C code needs to do. >> It remains C code. It remains in our core competence. >> >> Working with the rustls people has been nice and productive. The only thing >> I can report is that they come from the client TLS side and specific server >> needs require some explaining. There are things we can offer to them here. >> >> There are a lot of political things going on right now around OpenSSL and I >> definitely want to stay out of that. Again, we can offer this without having >> to switch ourself. Even better, customers can use this without needing to >> switch completely, as it co-exists. I think that fits into the concepts our >> server is designed with. >> >> Thanks for your time. >> >
Re: mod_tls as experimental module?
On 18 Nov 2021, at 19:48, ste...@eissing.org wrote: > How would you feel about adding mod_tls > (https://github.com/abetterinternet/mod_tls) as an experimental module to > Apache httpd? Having more choice is excellent. > For people who have not followed that development: > - it is a TLS 1.2/1.3 implementation based on rustls, > https://github.com/rustls/rustls > - the C API is rustls-ffi, found at https://github.com/rustls/rustls-ffi > - it is itself written in C, linking all the Rust things from the rustls-ffi > library > - it does not bring any Rust into our code base > - functionality wise, it is a clear subset of what mod_ssl offers via openssl > (e.g. no client certificates now and not as tweakable - at least for now) Client certs is a must for me. I know that they’re political, but my clients in finance don’t care. > - it can be co-loaded and co-used with mod_ssl on different ports or > front-/backend roles > - performance-wise, according to my plain vanilla tests, it is on par with > mod_ssl > > The decision to offer it downstream is of course then made by the distros, as > usual with experimental modules. And if and how it is then used rests with > the users. It is an offered alternative for people. > > What would be the benefit to the project? > - we offer people an alternative. If they feel the memory safety that Rust > offers is important to them, they can do it with Apache httpd for the TLS > stack. > - we could see how people react to this and adapt our TLS offering > accordingly. It being experimental, we remain free to change it. Or remove it > again. > > Organizational Things: > - the development was done by myself > - the work was sponsored by the ISRG (https://www.abetterinternet.org), the > org behind Let's Encrypt, as part of they "memory safety" initiative > (https://www.memorysafety.org) > > > Feedback appreciated, I lean towards adding it as an httpd subproject at this level: https://svn.apache.org/viewvc/httpd/ This frees you from all the complexity around experimental bits of httpd compared to fully supported bits. This means that practically, it can be packaged through channels like EPEL until it becomes stable, at which point the distros will pick it up. It also insulates us against external dependencies like rust. Languages wax and wane, should a rust2 coming along, or another language called oxide that’s better, we’re not left with aging code in our codebase. This is a problem that APR solves for us for operating systems. Regards, Graham —
Re: mod_tls as experimental module?
On Wed, Nov 24, 2021 at 11:19:17AM +0100, Yann Ylavic wrote: > However what would be a discussion without a naming dispute, mod_rustls? :p Agreed. At least as long as it's an experimental module. If it ever moves beyond experimental, then a rename back to mod_tls might make sense. vh Mads Toftum -- http://flickr.com/photos/q42/
Re: mod_tls as experimental module?
Hi Stefan, sorry for the lateness.. On Wed, Nov 24, 2021 at 10:46 AM ste...@eissing.org wrote: > > Coming back to this. Since there was no feedback on my post: are people > just too occupied/opposed/not interested? I looked at the code diagonally and it looks good to me (I like it and the safety guarantees of rust), thanks for the good work! +1 for experimental which will give us some margin. However what would be a discussion without a naming dispute, mod_rustls? :p (no strong opinion of course..). Cheers; Yann.
Re: mod_tls as experimental module?
> Am 24.11.2021 um 10:57 schrieb Joe Orton : > > Possibly no strong opinions? +1 from me anyway. > > How hard is it going to be to test in Travis? I have a test suite that can be added to our test/modules. Then we need to bring the rust tool chain into the test image and checkout/create the librustls. I can start a docker image to see what that needs. Kind Regards, Stefan > > On Wed, Nov 24, 2021 at 10:46:03AM +0100, ste...@eissing.org wrote: >> Coming back to this. Since there was no feedback on my post: are people >> just too occupied/opposed/not interested? >> >> Curious, >> Stefan >> >>> Am 18.11.2021 um 18:48 schrieb ste...@eissing.org: >>> >>> How would you feel about adding mod_tls >>> (https://github.com/abetterinternet/mod_tls) as an experimental module to >>> Apache httpd? >>> >>> For people who have not followed that development: >>> - it is a TLS 1.2/1.3 implementation based on rustls, >>> https://github.com/rustls/rustls >>> - the C API is rustls-ffi, found at https://github.com/rustls/rustls-ffi >>> - it is itself written in C, linking all the Rust things from the >>> rustls-ffi library >>> - it does not bring any Rust into our code base >>> - functionality wise, it is a clear subset of what mod_ssl offers via >>> openssl >>> (e.g. no client certificates now and not as tweakable - at least for now) >>> - it can be co-loaded and co-used with mod_ssl on different ports or >>> front-/backend roles >>> - performance-wise, according to my plain vanilla tests, it is on par with >>> mod_ssl >>> >>> The decision to offer it downstream is of course then made by the distros, >>> as usual with experimental modules. And if and how it is then used rests >>> with the users. It is an offered alternative for people. >>> >>> What would be the benefit to the project? >>> - we offer people an alternative. If they feel the memory safety that Rust >>> offers is important to them, they can do it with Apache httpd for the TLS >>> stack. >>> - we could see how people react to this and adapt our TLS offering >>> accordingly. It being experimental, we remain free to change it. Or remove >>> it again. >>> >>> Organizational Things: >>> - the development was done by myself >>> - the work was sponsored by the ISRG (https://www.abetterinternet.org), the >>> org behind Let's Encrypt, as part of they "memory safety" initiative >>> (https://www.memorysafety.org) >>> >>> >>> Feedback appreciated, >>> >>> Stefan >>> >>> PS. On a more personal note: >>> The way this project turned out was a clean separation between C and Rust. >>> The API offered by rustls-ffi is colored by Rust's immutability/borrowed >>> memory concepts, but there is nothing Rust special the C code needs to do. >>> It remains C code. It remains in our core competence. >>> >>> Working with the rustls people has been nice and productive. The only thing >>> I can report is that they come from the client TLS side and specific server >>> needs require some explaining. There are things we can offer to them here. >>> >>> There are a lot of political things going on right now around OpenSSL and I >>> definitely want to stay out of that. Again, we can offer this without >>> having to switch ourself. Even better, customers can use this without >>> needing to switch completely, as it co-exists. I think that fits into the >>> concepts our server is designed with. >>> >>> Thanks for your time. >>> >> >
Re: mod_tls as experimental module?
Possibly no strong opinions? +1 from me anyway. How hard is it going to be to test in Travis? On Wed, Nov 24, 2021 at 10:46:03AM +0100, ste...@eissing.org wrote: > Coming back to this. Since there was no feedback on my post: are people > just too occupied/opposed/not interested? > > Curious, > Stefan > > > Am 18.11.2021 um 18:48 schrieb ste...@eissing.org: > > > > How would you feel about adding mod_tls > > (https://github.com/abetterinternet/mod_tls) as an experimental module to > > Apache httpd? > > > > For people who have not followed that development: > > - it is a TLS 1.2/1.3 implementation based on rustls, > > https://github.com/rustls/rustls > > - the C API is rustls-ffi, found at https://github.com/rustls/rustls-ffi > > - it is itself written in C, linking all the Rust things from the > > rustls-ffi library > > - it does not bring any Rust into our code base > > - functionality wise, it is a clear subset of what mod_ssl offers via > > openssl > > (e.g. no client certificates now and not as tweakable - at least for now) > > - it can be co-loaded and co-used with mod_ssl on different ports or > > front-/backend roles > > - performance-wise, according to my plain vanilla tests, it is on par with > > mod_ssl > > > > The decision to offer it downstream is of course then made by the distros, > > as usual with experimental modules. And if and how it is then used rests > > with the users. It is an offered alternative for people. > > > > What would be the benefit to the project? > > - we offer people an alternative. If they feel the memory safety that Rust > > offers is important to them, they can do it with Apache httpd for the TLS > > stack. > > - we could see how people react to this and adapt our TLS offering > > accordingly. It being experimental, we remain free to change it. Or remove > > it again. > > > > Organizational Things: > > - the development was done by myself > > - the work was sponsored by the ISRG (https://www.abetterinternet.org), the > > org behind Let's Encrypt, as part of they "memory safety" initiative > > (https://www.memorysafety.org) > > > > > > Feedback appreciated, > > > > Stefan > > > > PS. On a more personal note: > > The way this project turned out was a clean separation between C and Rust. > > The API offered by rustls-ffi is colored by Rust's immutability/borrowed > > memory concepts, but there is nothing Rust special the C code needs to do. > > It remains C code. It remains in our core competence. > > > > Working with the rustls people has been nice and productive. The only thing > > I can report is that they come from the client TLS side and specific server > > needs require some explaining. There are things we can offer to them here. > > > > There are a lot of political things going on right now around OpenSSL and I > > definitely want to stay out of that. Again, we can offer this without > > having to switch ourself. Even better, customers can use this without > > needing to switch completely, as it co-exists. I think that fits into the > > concepts our server is designed with. > > > > Thanks for your time. > > >
Re: mod_tls as experimental module?
Coming back to this. Since there was no feedback on my post: are people just too occupied/opposed/not interested? Curious, Stefan > Am 18.11.2021 um 18:48 schrieb ste...@eissing.org: > > How would you feel about adding mod_tls > (https://github.com/abetterinternet/mod_tls) as an experimental module to > Apache httpd? > > For people who have not followed that development: > - it is a TLS 1.2/1.3 implementation based on rustls, > https://github.com/rustls/rustls > - the C API is rustls-ffi, found at https://github.com/rustls/rustls-ffi > - it is itself written in C, linking all the Rust things from the rustls-ffi > library > - it does not bring any Rust into our code base > - functionality wise, it is a clear subset of what mod_ssl offers via openssl > (e.g. no client certificates now and not as tweakable - at least for now) > - it can be co-loaded and co-used with mod_ssl on different ports or > front-/backend roles > - performance-wise, according to my plain vanilla tests, it is on par with > mod_ssl > > The decision to offer it downstream is of course then made by the distros, as > usual with experimental modules. And if and how it is then used rests with > the users. It is an offered alternative for people. > > What would be the benefit to the project? > - we offer people an alternative. If they feel the memory safety that Rust > offers is important to them, they can do it with Apache httpd for the TLS > stack. > - we could see how people react to this and adapt our TLS offering > accordingly. It being experimental, we remain free to change it. Or remove it > again. > > Organizational Things: > - the development was done by myself > - the work was sponsored by the ISRG (https://www.abetterinternet.org), the > org behind Let's Encrypt, as part of they "memory safety" initiative > (https://www.memorysafety.org) > > > Feedback appreciated, > > Stefan > > PS. On a more personal note: > The way this project turned out was a clean separation between C and Rust. > The API offered by rustls-ffi is colored by Rust's immutability/borrowed > memory concepts, but there is nothing Rust special the C code needs to do. It > remains C code. It remains in our core competence. > > Working with the rustls people has been nice and productive. The only thing I > can report is that they come from the client TLS side and specific server > needs require some explaining. There are things we can offer to them here. > > There are a lot of political things going on right now around OpenSSL and I > definitely want to stay out of that. Again, we can offer this without having > to switch ourself. Even better, customers can use this without needing to > switch completely, as it co-exists. I think that fits into the concepts our > server is designed with. > > Thanks for your time. >
mod_tls as experimental module?
How would you feel about adding mod_tls (https://github.com/abetterinternet/mod_tls) as an experimental module to Apache httpd? For people who have not followed that development: - it is a TLS 1.2/1.3 implementation based on rustls, https://github.com/rustls/rustls - the C API is rustls-ffi, found at https://github.com/rustls/rustls-ffi - it is itself written in C, linking all the Rust things from the rustls-ffi library - it does not bring any Rust into our code base - functionality wise, it is a clear subset of what mod_ssl offers via openssl (e.g. no client certificates now and not as tweakable - at least for now) - it can be co-loaded and co-used with mod_ssl on different ports or front-/backend roles - performance-wise, according to my plain vanilla tests, it is on par with mod_ssl The decision to offer it downstream is of course then made by the distros, as usual with experimental modules. And if and how it is then used rests with the users. It is an offered alternative for people. What would be the benefit to the project? - we offer people an alternative. If they feel the memory safety that Rust offers is important to them, they can do it with Apache httpd for the TLS stack. - we could see how people react to this and adapt our TLS offering accordingly. It being experimental, we remain free to change it. Or remove it again. Organizational Things: - the development was done by myself - the work was sponsored by the ISRG (https://www.abetterinternet.org), the org behind Let's Encrypt, as part of they "memory safety" initiative (https://www.memorysafety.org) Feedback appreciated, Stefan PS. On a more personal note: The way this project turned out was a clean separation between C and Rust. The API offered by rustls-ffi is colored by Rust's immutability/borrowed memory concepts, but there is nothing Rust special the C code needs to do. It remains C code. It remains in our core competence. Working with the rustls people has been nice and productive. The only thing I can report is that they come from the client TLS side and specific server needs require some explaining. There are things we can offer to them here. There are a lot of political things going on right now around OpenSSL and I definitely want to stay out of that. Again, we can offer this without having to switch ourself. Even better, customers can use this without needing to switch completely, as it co-exists. I think that fits into the concepts our server is designed with. Thanks for your time.
mod_tls, protocol and cipher plans
I opened an issue about protocol and cipher configuration plan in mod_tls: https://github.com/icing/mod_tls/issues/1 - Stefan
Re: mod_tls
From: "Gonyou, Austin" <[EMAIL PROTECTED]> Sent: Wednesday, August 29, 2001 11:48 AM > The referrence here is one about all the filters used by apache 2.0. If > there is a filter bucket in APR, it's understandable that Apache 2.0 modules > will have 2 parts. The logic piece and the filter piece. As far as I can > tell, the filter mechanism allows for some distinct advantages and makes for > a very flexible configuration framework. My issue here is that if mod_tls is > sacrificed, then what's the point of using filters at all anyway? That said, > could it be said that you CAN write a module for Apache 2.0 without needing > the use of filters? If so, then that makes sense. I think we are confusing Content filters with Connection Filters. Connection Filters can rarely be divorced from the protocol. E.g., chunking and byterange filters can't be split (easily) from the http protocol. An ssl filter can't be split from the negotiation of the ssl conversation. When we implement Connection-Upgrade (SSL over IP) then the extention needs to be burried directly into mod_ssl's https layer. I can only see splitting this into two parts from it's current state. One part would be the https module. The other part would be all the client negotiation that's left over, with hooks between. I'm not certain we wish to 'extend' tls into this connection aspect. To get it right, it's easier to split out https_protocol and proxy_https from the rich set of mod_ssl features. Then the ssh protocol will stand alone, with an appropriate _protocol module, for future expansion. I'm going to state, right now, that I see this (and the further 'rearrangement' of modules/http into a stand-alone/removable component) as httpd-2.1 features. Right now modules/http contains a lot of core features, and the core still contains a bunch of http features. The third split in 2.1 would be mod_filesystem, for all the file hackishness in the core today ;) So I'll call these for a vote... a removable modules/http (fully segregated from core) is not an Apache 2.0 showstopper. a removable modules/https (fully segregated from mod_ssl) is not an Apache 2.0 showstopper. a removable mod_filesystem (fully segregated from core) is not an Apache 2.0 showstopper. These above-mentioned features, once complete, will instigate the 2.1 bump. Today, we pull mod_tls from the distribution till we do the split above for 2.1. This doesn't mean we don't continue to focus on Content filters until the semantics are right (see my next post a bit later) - it just means that Connection filters have some growing to do :) Bill
RE: mod_tls
On Wed, 29 Aug 2001, Gonyou, Austin wrote: > The referrence here is one about all the filters used by apache 2.0. > If there is a filter bucket in APR, What do you mean by "filter bucket"? > it's understandable that Apache 2.0 modules will have 2 parts. The > logic piece and the filter piece. Not necessarily. Many filter modules will basically ONLY be a filter--whatever logic there is goes inside the filter itself. The core has several filters that are examples of this. > As far as I can tell, the filter mechanism allows for some distinct > advantages and makes for a very flexible configuration framework. My > issue here is that if mod_tls is sacrificed, then what's the point of > using filters at all anyway? Perhaps you're missing the fact that mod_ssl *is* using filters on its own... it simply has a duplicate copy of the filter logic from mod_tls. The original idea was that mod_tls would be the filter and mod_ssl would add the "extra features", but in fact they're not really "extra" at all, and really are necessary support functionality. So it makes sense to have it all in one module. But even if mod_tls gets taken out, no functionality is changed; we just remove the duplicate (now outdated) copy of the filter logic that remains in mod_tls in favor of the improved copy of that same logic that is now in mod_ssl. > That said, could it be said that you CAN write a module for Apache 2.0 > without needing the use of filters? Sure, that's no different from 1.3. You can write a handler or an auth module or any number of things that make no use of filters whatsoever. BUT (to answer Sunitha's question), filters make some coding tasks a helluva lot easier. SSL is one of them. Why? Because in some cases (mod_ssl, mod_include, just to name a few), all you want to do is morph the content as it passes through you in some way (encrypt/decrypt, parse for SSI tags, etc). You are neither the generator of the content nor the ultimate consumer of the content, just a filter that sits in between. And multiple filters can be stacked on top of each other, which adds all sorts of flexibility. So COULD you write mod_ssl for Apache 2.0 as something other than a filter? Probably, but it'd involve lots of extra work and clever hacks much like what it took to get an SSL-aware 1.3. Filters take care of much of that work for you behind the scenes. --Cliff
RE: mod_tls
In 1.3.x, it was so happening that Apache/mod_ssl registers the connection id (fd) with OpenSSL, and then OpenSSL takes over the connection handling as well as the protocol communication stuff from that point onwards.. In 2.x, with the introduction of filters, OpenSSL nolonger talks directly to the client directly.. Instead, all the data comes/goes thru' the filters (*_NETWORK_*).. The connection handling stuff is done at the APR level.. Thus, the OpenSSL is used only for the protocol logic ONLY and not for handling any connection details.. Pl. let me know if you need more details.. Thanks -Madhu -Original Message- From: Sunitha Kumar [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 29, 2001 9:39 AM To: [EMAIL PROTECTED] Subject: Re: mod_tls could some one give pointers on the need for filters around the ssl code. What would be lost if those filters don't exist. And, what was the need to put them in, originally. thanks, sunitha Gonyou, Austin wrote: >The referrence here is one about all the filters used by apache 2.0. If >there is a filter bucket in APR, it's understandable that Apache 2.0 modules >will have 2 parts. The logic piece and the filter piece. As far as I can >tell, the filter mechanism allows for some distinct advantages and makes for >a very flexible configuration framework. My issue here is that if mod_tls is >sacrificed, then what's the point of using filters at all anyway? That said, >could it be said that you CAN write a module for Apache 2.0 without needing >the use of filters? If so, then that makes sense. >
Re: mod_tls
On Wednesday 29 August 2001 09:39, Sunitha Kumar wrote: The SSL filters are what actually does the encryption/decryption. If they don't exist, we don't have SSL. Everything else is just to control how the filters work. As for mod_tls, what you are missing, is that the filters have been copied from mod_tls to mod_ssl. Right now, we have two modules with the same basic filters, except the mod_ssl filters have more bug fixes. Ryan > could some one give pointers on the need for filters around the ssl > code. What would be lost if those filters don't exist. And, what was the > need to put them in, originally. > > thanks, > sunitha > > Gonyou, Austin wrote: > >The referrence here is one about all the filters used by apache 2.0. If > >there is a filter bucket in APR, it's understandable that Apache 2.0 > > modules will have 2 parts. The logic piece and the filter piece. As far > > as I can tell, the filter mechanism allows for some distinct advantages > > and makes for a very flexible configuration framework. My issue here is > > that if mod_tls is sacrificed, then what's the point of using filters at > > all anyway? That said, could it be said that you CAN write a module for > > Apache 2.0 without needing the use of filters? If so, then that makes > > sense. -- __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: mod_tls
could some one give pointers on the need for filters around the ssl code. What would be lost if those filters don't exist. And, what was the need to put them in, originally. thanks, sunitha Gonyou, Austin wrote: >The referrence here is one about all the filters used by apache 2.0. If >there is a filter bucket in APR, it's understandable that Apache 2.0 modules >will have 2 parts. The logic piece and the filter piece. As far as I can >tell, the filter mechanism allows for some distinct advantages and makes for >a very flexible configuration framework. My issue here is that if mod_tls is >sacrificed, then what's the point of using filters at all anyway? That said, >could it be said that you CAN write a module for Apache 2.0 without needing >the use of filters? If so, then that makes sense. >
RE: mod_tls
The referrence here is one about all the filters used by apache 2.0. If there is a filter bucket in APR, it's understandable that Apache 2.0 modules will have 2 parts. The logic piece and the filter piece. As far as I can tell, the filter mechanism allows for some distinct advantages and makes for a very flexible configuration framework. My issue here is that if mod_tls is sacrificed, then what's the point of using filters at all anyway? That said, could it be said that you CAN write a module for Apache 2.0 without needing the use of filters? If so, then that makes sense. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: [EMAIL PROTECTED] > -Original Message- > From: MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) > [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, August 28, 2001 9:39 PM > To: '[EMAIL PROTECTED]' > Subject: RE: mod_tls > > > 'not sure what you mean by "entire filter scheme" - if you're > referring to > the proposal to seperate the HTTPS and the SSL filter logic - > I'd rather > prefer to leave SSL as it is (especially if it works with > other protocol > modules).. > > Thanks > -Madhu > > -Original Message- > From: Gonyou, Austin [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, August 28, 2001 1:08 PM > To: '[EMAIL PROTECTED]' > Subject: RE: mod_tls > > > Kewl. Less maintenance all around. Is the entire filter > scheme doomed like > this though? > > -- > Austin Gonyou > Systems Architect, CCNA > Coremetrics, Inc. > Phone: 512-796-9023 > email: [EMAIL PROTECTED] > > > -Original Message- > > From: Ryan Bloom [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, August 28, 2001 1:58 AM > > To: [EMAIL PROTECTED]; Doug MacEachern > > Cc: MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) > > Subject: Re: mod_tls > > > > > > On Monday 27 August 2001 23:03, Doug MacEachern wrote: > > > On Thu, 23 Aug 2001, Ryan Bloom wrote: > > > > Because mod_ssl only implements the SSL wrapping for > > HTTP. The idea is > > > > that the filters go in mod_tls, and mod_ssl just has the > > logic to make > > > > the filters work for HTTP. That way, SSL can work with > > POP3, NNTP, and > > > > the proxy. > > > > > > i think mod_ssl should work with all protocols (it works > > with nntp right > > > now). mod_ssl provides features such as: > > > CRLs > > > session caching > > > per-location renegotation > > > SSLRequire > > > logging > > > var lookups > > > and so on that are not http specific. > > > > > > there is a bit more effort to get a protocol module such as > > nntp working > > > both with and without ssl. for example with nntp when the > > first client > > > connects it does not send a request (like http clients do), > > but awaits a > > > 200 - ready response. to work with ssl, an nntp protocol > > module needs to > > > first call get_brigade to trigger the initial ssl > > negotiation. but the > > > same issue is there with mod_tls. personally, i don't > > think its worth > > > the effort to maintain both mod_tls and mod_ssl. effort > > would be better > > > spent modularizing mod_ssl to support other protocols if needed. > > > > Cool, if this works, then we should just ditch mod_tls. > > > > Ryan > > > > __ > > Ryan Bloom [EMAIL PROTECTED] > > Covalent Technologies [EMAIL PROTECTED] > > -- > > >
RE: mod_tls
'not sure what you mean by "entire filter scheme" - if you're referring to the proposal to seperate the HTTPS and the SSL filter logic - I'd rather prefer to leave SSL as it is (especially if it works with other protocol modules).. Thanks -Madhu -Original Message- From: Gonyou, Austin [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 28, 2001 1:08 PM To: '[EMAIL PROTECTED]' Subject: RE: mod_tls Kewl. Less maintenance all around. Is the entire filter scheme doomed like this though? -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: [EMAIL PROTECTED] > -Original Message- > From: Ryan Bloom [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, August 28, 2001 1:58 AM > To: [EMAIL PROTECTED]; Doug MacEachern > Cc: MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) > Subject: Re: mod_tls > > > On Monday 27 August 2001 23:03, Doug MacEachern wrote: > > On Thu, 23 Aug 2001, Ryan Bloom wrote: > > > Because mod_ssl only implements the SSL wrapping for > HTTP. The idea is > > > that the filters go in mod_tls, and mod_ssl just has the > logic to make > > > the filters work for HTTP. That way, SSL can work with > POP3, NNTP, and > > > the proxy. > > > > i think mod_ssl should work with all protocols (it works > with nntp right > > now). mod_ssl provides features such as: > > CRLs > > session caching > > per-location renegotation > > SSLRequire > > logging > > var lookups > > and so on that are not http specific. > > > > there is a bit more effort to get a protocol module such as > nntp working > > both with and without ssl. for example with nntp when the > first client > > connects it does not send a request (like http clients do), > but awaits a > > 200 - ready response. to work with ssl, an nntp protocol > module needs to > > first call get_brigade to trigger the initial ssl > negotiation. but the > > same issue is there with mod_tls. personally, i don't > think its worth > > the effort to maintain both mod_tls and mod_ssl. effort > would be better > > spent modularizing mod_ssl to support other protocols if needed. > > Cool, if this works, then we should just ditch mod_tls. > > Ryan > > __ > Ryan Bloom[EMAIL PROTECTED] > Covalent Technologies [EMAIL PROTECTED] > -- >
RE: mod_tls
Kewl. Less maintenance all around. Is the entire filter scheme doomed like this though? -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: [EMAIL PROTECTED] > -Original Message- > From: Ryan Bloom [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, August 28, 2001 1:58 AM > To: [EMAIL PROTECTED]; Doug MacEachern > Cc: MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) > Subject: Re: mod_tls > > > On Monday 27 August 2001 23:03, Doug MacEachern wrote: > > On Thu, 23 Aug 2001, Ryan Bloom wrote: > > > Because mod_ssl only implements the SSL wrapping for > HTTP. The idea is > > > that the filters go in mod_tls, and mod_ssl just has the > logic to make > > > the filters work for HTTP. That way, SSL can work with > POP3, NNTP, and > > > the proxy. > > > > i think mod_ssl should work with all protocols (it works > with nntp right > > now). mod_ssl provides features such as: > > CRLs > > session caching > > per-location renegotation > > SSLRequire > > logging > > var lookups > > and so on that are not http specific. > > > > there is a bit more effort to get a protocol module such as > nntp working > > both with and without ssl. for example with nntp when the > first client > > connects it does not send a request (like http clients do), > but awaits a > > 200 - ready response. to work with ssl, an nntp protocol > module needs to > > first call get_brigade to trigger the initial ssl > negotiation. but the > > same issue is there with mod_tls. personally, i don't > think its worth > > the effort to maintain both mod_tls and mod_ssl. effort > would be better > > spent modularizing mod_ssl to support other protocols if needed. > > Cool, if this works, then we should just ditch mod_tls. > > Ryan > > __ > Ryan Bloom[EMAIL PROTECTED] > Covalent Technologies [EMAIL PROTECTED] > -- >
Re: mod_tls
On Monday 27 August 2001 23:03, Doug MacEachern wrote: > On Thu, 23 Aug 2001, Ryan Bloom wrote: > > Because mod_ssl only implements the SSL wrapping for HTTP. The idea is > > that the filters go in mod_tls, and mod_ssl just has the logic to make > > the filters work for HTTP. That way, SSL can work with POP3, NNTP, and > > the proxy. > > i think mod_ssl should work with all protocols (it works with nntp right > now). mod_ssl provides features such as: > CRLs > session caching > per-location renegotation > SSLRequire > logging > var lookups > and so on that are not http specific. > > there is a bit more effort to get a protocol module such as nntp working > both with and without ssl. for example with nntp when the first client > connects it does not send a request (like http clients do), but awaits a > 200 - ready response. to work with ssl, an nntp protocol module needs to > first call get_brigade to trigger the initial ssl negotiation. but the > same issue is there with mod_tls. personally, i don't think its worth > the effort to maintain both mod_tls and mod_ssl. effort would be better > spent modularizing mod_ssl to support other protocols if needed. Cool, if this works, then we should just ditch mod_tls. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: mod_tls
On Thu, 23 Aug 2001, Ryan Bloom wrote: > > Because mod_ssl only implements the SSL wrapping for HTTP. The idea is that > the filters go in mod_tls, and mod_ssl just has the logic to make the filters work > for HTTP. That way, SSL can work with POP3, NNTP, and the proxy. i think mod_ssl should work with all protocols (it works with nntp right now). mod_ssl provides features such as: CRLs session caching per-location renegotation SSLRequire logging var lookups and so on that are not http specific. there is a bit more effort to get a protocol module such as nntp working both with and without ssl. for example with nntp when the first client connects it does not send a request (like http clients do), but awaits a 200 - ready response. to work with ssl, an nntp protocol module needs to first call get_brigade to trigger the initial ssl negotiation. but the same issue is there with mod_tls. personally, i don't think its worth the effort to maintain both mod_tls and mod_ssl. effort would be better spent modularizing mod_ssl to support other protocols if needed.
RE: mod_tls
Agreed. Thanks for all the thoughts! -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: [EMAIL PROTECTED] > -Original Message- > From: Ryan Bloom [mailto:[EMAIL PROTECTED]] > Sent: Thursday, August 23, 2001 11:57 AM > To: [EMAIL PROTECTED]; MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) > Subject: Re: mod_tls > > > > Probably, but renames are a PITA. > > Ryan > > On Thursday 23 August 2001 09:47, MATHIHALLI,MADHUSUDAN > (HP-Cupertino,ex1) wrote: > > Ok.. So, what you mean is to have 2 modules - (1). mod_ssl > to implement the > > HTTPS stuff, and (2). mod_tls which does just the SSL > filtering. That's > > great !!.. > > > > So, in that case, is it worthwhile to rename mod_tls to > something like > > ssl_filter and mod_ssl to mod_https ?.. > > > > > > Thanks > > -Madhu > > > > > > -Original Message- > > From: Ryan Bloom [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, August 23, 2001 9:37 AM > > To: [EMAIL PROTECTED]; MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) > > Subject: Re: mod_tls > > > > > > > > Because mod_ssl only implements the SSL wrapping for HTTP. > The idea is > > that the filters go in mod_tls, and mod_ssl just has the > logic to make the > > filters work > > for HTTP. That way, SSL can work with POP3, NNTP, and the proxy. > > > > Ryan > > > > On Thursday 23 August 2001 09:33, MATHIHALLI,MADHUSUDAN > (HP-Cupertino,ex1) > > > > wrote: > > > Why ?..I see mod_ssl as a superset of mod_tls.. Both > mod_tls and mod_ssl > > > are capable of SSL & TLS protocol comm., and they both > use the same > > > > utility > > > > > (OpenSSL) for achieving it.. > > > (AFAIK, mod_ssl goes a step further by being compatible > with SSL-C). > > > > > > The only reason why mod_tls has to be maintained (if at > all) is because > > > it's a lot simple to understand and easier to manipulate.. > > > > > > Just my thoughts.. > > > -Madhu > > > > > > -Original Message- > > > From: Ryan Bloom [mailto:[EMAIL PROTECTED]] > > > Sent: Thursday, August 23, 2001 7:55 AM > > > To: [EMAIL PROTECTED]; Greg Ames > > > Subject: Re: mod_tls > > > > > > > > > > > > At some point, the mod_ssl filters should be removed from > mod_ssl, and > > > put into mod_tls. That way, the same filters can be used > for the proxy, > > > and other > > > protocols, without the mod_ssl wrapper stuff. > > > > > > Ryan > > > > > > On Thursday 23 August 2001 06:41, Greg Ames wrote: > > > > Cliff Woolley wrote: > > > > > I'm sure this has been discussed, but someone please > remind me what > > > > was > > > > > > > decided. Are we going to continue to maintain > mod_tls? I'm sure > > > > there > > > > > > > are some changes that have been made to mod_ssl that > would need to be > > > > > ported over to mod_tls if we are. > > > > > > > > > > > > > > > > I believe mod_tls is a layer that isolates mod_ssl from > the filter > > > > chain in 2.0. So we need both. If someone wrote an > alterative to > > > > mod_ssl, presumably that would use mod_tls as well. > > > > > > > > Greg > > -- > > __ > Ryan Bloom[EMAIL PROTECTED] > Covalent Technologies [EMAIL PROTECTED] > -- >
Re: mod_tls
Probably, but renames are a PITA. Ryan On Thursday 23 August 2001 09:47, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote: > Ok.. So, what you mean is to have 2 modules - (1). mod_ssl to implement the > HTTPS stuff, and (2). mod_tls which does just the SSL filtering. That's > great !!.. > > So, in that case, is it worthwhile to rename mod_tls to something like > ssl_filter and mod_ssl to mod_https ?.. > > > Thanks > -Madhu > > > -Original Message- > From: Ryan Bloom [mailto:[EMAIL PROTECTED]] > Sent: Thursday, August 23, 2001 9:37 AM > To: [EMAIL PROTECTED]; MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) > Subject: Re: mod_tls > > > > Because mod_ssl only implements the SSL wrapping for HTTP. The idea is > that the filters go in mod_tls, and mod_ssl just has the logic to make the > filters work > for HTTP. That way, SSL can work with POP3, NNTP, and the proxy. > > Ryan > > On Thursday 23 August 2001 09:33, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) > > wrote: > > Why ?..I see mod_ssl as a superset of mod_tls.. Both mod_tls and mod_ssl > > are capable of SSL & TLS protocol comm., and they both use the same > > utility > > > (OpenSSL) for achieving it.. > > (AFAIK, mod_ssl goes a step further by being compatible with SSL-C). > > > > The only reason why mod_tls has to be maintained (if at all) is because > > it's a lot simple to understand and easier to manipulate.. > > > > Just my thoughts.. > > -Madhu > > > > -Original Message- > > From: Ryan Bloom [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, August 23, 2001 7:55 AM > > To: [EMAIL PROTECTED]; Greg Ames > > Subject: Re: mod_tls > > > > > > > > At some point, the mod_ssl filters should be removed from mod_ssl, and > > put into mod_tls. That way, the same filters can be used for the proxy, > > and other > > protocols, without the mod_ssl wrapper stuff. > > > > Ryan > > > > On Thursday 23 August 2001 06:41, Greg Ames wrote: > > > Cliff Woolley wrote: > > > > I'm sure this has been discussed, but someone please remind me what > > was > > > > > decided. Are we going to continue to maintain mod_tls? I'm sure > > there > > > > > are some changes that have been made to mod_ssl that would need to be > > > > ported over to mod_tls if we are. > > > > > > > > > > > > I believe mod_tls is a layer that isolates mod_ssl from the filter > > > chain in 2.0. So we need both. If someone wrote an alterative to > > > mod_ssl, presumably that would use mod_tls as well. > > > > > > Greg -- __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
RE: mod_tls
Ok.. So, what you mean is to have 2 modules - (1). mod_ssl to implement the HTTPS stuff, and (2). mod_tls which does just the SSL filtering. That's great !!.. So, in that case, is it worthwhile to rename mod_tls to something like ssl_filter and mod_ssl to mod_https ?.. Thanks -Madhu -Original Message- From: Ryan Bloom [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 23, 2001 9:37 AM To: [EMAIL PROTECTED]; MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) Subject: Re: mod_tls Because mod_ssl only implements the SSL wrapping for HTTP. The idea is that the filters go in mod_tls, and mod_ssl just has the logic to make the filters work for HTTP. That way, SSL can work with POP3, NNTP, and the proxy. Ryan On Thursday 23 August 2001 09:33, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote: > Why ?..I see mod_ssl as a superset of mod_tls.. Both mod_tls and mod_ssl > are capable of SSL & TLS protocol comm., and they both use the same utility > (OpenSSL) for achieving it.. > (AFAIK, mod_ssl goes a step further by being compatible with SSL-C). > > The only reason why mod_tls has to be maintained (if at all) is because > it's a lot simple to understand and easier to manipulate.. > > Just my thoughts.. > -Madhu > > -Original Message- > From: Ryan Bloom [mailto:[EMAIL PROTECTED]] > Sent: Thursday, August 23, 2001 7:55 AM > To: [EMAIL PROTECTED]; Greg Ames > Subject: Re: mod_tls > > > > At some point, the mod_ssl filters should be removed from mod_ssl, and put > into mod_tls. That way, the same filters can be used for the proxy, and > other > protocols, without the mod_ssl wrapper stuff. > > Ryan > > On Thursday 23 August 2001 06:41, Greg Ames wrote: > > Cliff Woolley wrote: > > > I'm sure this has been discussed, but someone please remind me what was > > > decided. Are we going to continue to maintain mod_tls? I'm sure there > > > are some changes that have been made to mod_ssl that would need to be > > > ported over to mod_tls if we are. > > > > > > > > I believe mod_tls is a layer that isolates mod_ssl from the filter chain > > in 2.0. So we need both. If someone wrote an alterative to mod_ssl, > > presumably that would use mod_tls as well. > > > > Greg -- __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: mod_tls
Because mod_ssl only implements the SSL wrapping for HTTP. The idea is that the filters go in mod_tls, and mod_ssl just has the logic to make the filters work for HTTP. That way, SSL can work with POP3, NNTP, and the proxy. Ryan On Thursday 23 August 2001 09:33, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote: > Why ?..I see mod_ssl as a superset of mod_tls.. Both mod_tls and mod_ssl > are capable of SSL & TLS protocol comm., and they both use the same utility > (OpenSSL) for achieving it.. > (AFAIK, mod_ssl goes a step further by being compatible with SSL-C). > > The only reason why mod_tls has to be maintained (if at all) is because > it's a lot simple to understand and easier to manipulate.. > > Just my thoughts.. > -Madhu > > -Original Message- > From: Ryan Bloom [mailto:[EMAIL PROTECTED]] > Sent: Thursday, August 23, 2001 7:55 AM > To: [EMAIL PROTECTED]; Greg Ames > Subject: Re: mod_tls > > > > At some point, the mod_ssl filters should be removed from mod_ssl, and put > into mod_tls. That way, the same filters can be used for the proxy, and > other > protocols, without the mod_ssl wrapper stuff. > > Ryan > > On Thursday 23 August 2001 06:41, Greg Ames wrote: > > Cliff Woolley wrote: > > > I'm sure this has been discussed, but someone please remind me what was > > > decided. Are we going to continue to maintain mod_tls? I'm sure there > > > are some changes that have been made to mod_ssl that would need to be > > > ported over to mod_tls if we are. > > > > > > > > I believe mod_tls is a layer that isolates mod_ssl from the filter chain > > in 2.0. So we need both. If someone wrote an alterative to mod_ssl, > > presumably that would use mod_tls as well. > > > > Greg -- __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
RE: mod_tls
Why ?..I see mod_ssl as a superset of mod_tls.. Both mod_tls and mod_ssl are capable of SSL & TLS protocol comm., and they both use the same utility (OpenSSL) for achieving it.. (AFAIK, mod_ssl goes a step further by being compatible with SSL-C). The only reason why mod_tls has to be maintained (if at all) is because it's a lot simple to understand and easier to manipulate.. Just my thoughts.. -Madhu -Original Message- From: Ryan Bloom [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 23, 2001 7:55 AM To: [EMAIL PROTECTED]; Greg Ames Subject: Re: mod_tls At some point, the mod_ssl filters should be removed from mod_ssl, and put into mod_tls. That way, the same filters can be used for the proxy, and other protocols, without the mod_ssl wrapper stuff. Ryan On Thursday 23 August 2001 06:41, Greg Ames wrote: > Cliff Woolley wrote: > > I'm sure this has been discussed, but someone please remind me what was > > decided. Are we going to continue to maintain mod_tls? I'm sure there > > are some changes that have been made to mod_ssl that would need to be > > ported over to mod_tls if we are. > > > > I believe mod_tls is a layer that isolates mod_ssl from the filter chain > in 2.0. So we need both. If someone wrote an alterative to mod_ssl, > presumably that would use mod_tls as well. > > Greg -- __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
RE: mod_tls
Here's a question around mod_tls. I think this is from a "grown up"(verb) perspective of the maturity of SSL/TLS. Since SSL is technically on it's last iteration of Versioning, and TLS is supposed to take place of SSL, could we push towards the "newer" standard, and rename mod_ssl to mod_tls? Just a though, there's a lot in a name. Currently mod_ssl supports ssl/tls. Could it perhaps be said that mod_tls supports tls/ssl then? I'm not trying to start flames on this, but it could be worth considering as the TLS toolkit. Just a though. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: [EMAIL PROTECTED]
Re: mod_tls
At some point, the mod_ssl filters should be removed from mod_ssl, and put into mod_tls. That way, the same filters can be used for the proxy, and other protocols, without the mod_ssl wrapper stuff. Ryan On Thursday 23 August 2001 06:41, Greg Ames wrote: > Cliff Woolley wrote: > > I'm sure this has been discussed, but someone please remind me what was > > decided. Are we going to continue to maintain mod_tls? I'm sure there > > are some changes that have been made to mod_ssl that would need to be > > ported over to mod_tls if we are. > > > > I believe mod_tls is a layer that isolates mod_ssl from the filter chain > in 2.0. So we need both. If someone wrote an alterative to mod_ssl, > presumably that would use mod_tls as well. > > Greg -- __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: mod_tls
On Thu, 23 Aug 2001, Greg Ames wrote: > Cliff Woolley wrote: > > > > I'm sure this has been discussed, but someone please remind me what was > > decided. Are we going to continue to maintain mod_tls? I'm sure there > > are some changes that have been made to mod_ssl that would need to be > > ported over to mod_tls if we are. > > > > I believe mod_tls is a layer that isolates mod_ssl from the filter chain > in 2.0. So we need both. If someone wrote an alterative to mod_ssl, > presumably that would use mod_tls as well. Actually, mod_ssl duplicates the logic of mod_tls currently. You don't need mod_tls to use mod_ssl. Either mod_ssl needs to get the logic stripped out and it needs to be hooked in to mod_tls (and the fixes from mod_ssl need to get shifted over to mod_tls), or mod_tls needs to go away. I prefer the latter... --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: mod_tls
Cliff Woolley wrote: > > I'm sure this has been discussed, but someone please remind me what was > decided. Are we going to continue to maintain mod_tls? I'm sure there > are some changes that have been made to mod_ssl that would need to be > ported over to mod_tls if we are. I believe mod_tls is a layer that isolates mod_ssl from the filter chain in 2.0. So we need both. If someone wrote an alterative to mod_ssl, presumably that would use mod_tls as well. Greg
mod_tls
I'm sure this has been discussed, but someone please remind me what was decided. Are we going to continue to maintain mod_tls? I'm sure there are some changes that have been made to mod_ssl that would need to be ported over to mod_tls if we are. --Cliff Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
