relayd: http protocol not supporting some http methods

[Michael Lechtermann]

Hi,

I have recently configured relayd as SSL accelerator and it is working really great. However it seems that not all http methods that are mentioned in the man page are actually supported by the http protocol.

method name
Match the HTTP request method. The method is specified by name
and can be either CONNECT, COPY, DELETE, GET, HEAD, LOCK, MKCOL,
MOVE, OPTIONS, PATCH, POST, PROPFIND, PROPPATCH, PUT, TRACE, or
UNLOCK.

The above list is from "man relayd.conf" and I would assume that those methods, if mentioned, are fully supported, however when trying to use Apache2 with mod_dav_svn (ap2-subversion) relayd somehow breaks it:

# svn up
svn: Server sent unexpected return value (400 Bad Request) in response to OPTIONS request for 'https://<url>/svn/repo'

This was tested using OpenBSD 5.9. If more information is required, please say so.

Regards,
Michael

[Reyk Floeter]

Hi,

thanks, this is the second report regarding WebDAV since yesterday. I'll have a look at this when I'm back home next week.

Reyk

[Paul Fariello]

Hi,

I've encountered the exact same issue. I think this is due to a miss
handling of message-body.

RFC2616 states in chapter 4.3 that:

> The presence of a message-body in a request is signaled by the
> inclusion of a Content-Length or Transfer-Encoding header field in
> the request's message-headers. A message-body MUST NOT be included in
> a request if the specification of the request method (section 5.1.1)
> does not allow sending an entity-body in requests. A server SHOULD
> read and forward a message-body on any request; if the request method
> does not include defined semantics for an entity-body, then the
> message-body SHOULD be ignored when handling the request.
>

Thus we should not ignore message-body for unknown methods by forcing
cre->toread to TOREAD_HTTP_HEADER.

Please find attached a patch that just allow http request to have a
message-body whatever the method is.

Regards,
Paul

> 2016-06-24 11:01:03
> <re...@openbsd.org>:

[Paul Fariello]

Hi,

here is an updated patch adding support for WebDAV Versioning Extensions
RFC3253.

Regards,
Paul

> Index: relay_http.c
> ===================================================================
> RCS file: /cvs/src/usr.sbin/relayd/relay_http.c,v
> retrieving revision 1.55
> diff -r1.55 relay_http.c
> 375a376
> > default:
> 385,389d385
> < break;
> < default:
> < /* HTTP handler */
> < cre->toread = TOREAD_HTTP_HEADER;
> < bev->readcb = relay_read_http;


--
Paul Fariello

PGP: 0x672CDD2031AAF49B

[Reyk Floeter]

On Fri, Jun 24, 2016 at 10:21:16AM +0200, Michael Lechtermann wrote:
> Hi,
>
> I have recently configured relayd as SSL accelerator and it is working really great. However it seems that not all http methods that are mentioned in the man page are actually supported by the http protocol.
>
> method name
> Match the HTTP request method. The method is specified by name
> and can be either CONNECT, COPY, DELETE, GET, HEAD, LOCK, MKCOL,
> MOVE, OPTIONS, PATCH, POST, PROPFIND, PROPPATCH, PUT, TRACE, or
> UNLOCK.
>
> The above list is from "man relayd.conf" and I would assume that those methods, if mentioned, are fully supported, however when trying to use Apache2 with mod_dav_svn (ap2-subversion) relayd somehow breaks it:
>
> # svn up
> svn: Server sent unexpected return value (400 Bad Request) in response to OPTIONS request for 'https://<url>/svn/repo'
>
> This was tested using OpenBSD 5.9. If more information is required, please say so.
>

I once added the well-known webdav methods to httpd, the attached diff
syncs it to relayd. Could you give it a try?

Reyk

Index: usr.sbin/relayd/http.h
===================================================================
RCS file: /cvs/src/usr.sbin/relayd/http.h,v
retrieving revision 1.7
diff -u -p -u -p -r1.7 http.h
--- usr.sbin/relayd/http.h 11 Jun 2015 18:49:09 -0000 1.7
+++ usr.sbin/relayd/http.h 27 Jul 2016 09:36:35 -0000
@@ -1,7 +1,7 @@
-/* $OpenBSD: http.h,v 1.7 2015/06/11 18:49:09 reyk Exp $ */
+/* $OpenBSD: http.h,v 1.13 2015/06/11 18:49:09 reyk Exp $ */

/*
- * Copyright (c) 2012 - 2014 Reyk Floeter <re...@openbsd.org>
+ * Copyright (c) 2012 - 2015 Reyk Floeter <re...@openbsd.org>
*
* Permission to use, copy, modify, and distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
@@ -44,6 +44,32 @@ enum httpmethod {
HTTP_METHOD_LOCK,
HTTP_METHOD_UNLOCK,

+ /* WebDAV Versioning Extension, RFC 3253 */
+ HTTP_METHOD_VERSION_CONTROL,
+ HTTP_METHOD_REPORT,
+ HTTP_METHOD_CHECKOUT,
+ HTTP_METHOD_CHECKIN,
+ HTTP_METHOD_UNCHECKOUT,
+ HTTP_METHOD_MKWORKSPACE,
+ HTTP_METHOD_UPDATE,
+ HTTP_METHOD_LABEL,
+ HTTP_METHOD_MERGE,
+ HTTP_METHOD_BASELINE_CONTROL,
+ HTTP_METHOD_MKACTIVITY,
+
+ /* WebDAV Ordered Collections, RFC 3648 */
+ HTTP_METHOD_ORDERPATCH,
+
+ /* WebDAV Access Control, RFC 3744 */
+ HTTP_METHOD_ACL,
+
+ /* WebDAV Redirect Reference Resources, RFC 4437 */
+ HTTP_METHOD_MKREDIRECTREF,
+ HTTP_METHOD_UPDATEREDIRECTREF,
+
+ /* WebDAV Search, RFC 5323 */
+ HTTP_METHOD_SEARCH,
+
/* PATCH, RFC 5789 */
HTTP_METHOD_PATCH,

@@ -71,6 +97,22 @@ struct http_method {
{ HTTP_METHOD_MOVE, "MOVE" }, \
{ HTTP_METHOD_LOCK, "LOCK" }, \
{ HTTP_METHOD_UNLOCK, "UNLOCK" }, \
+ { HTTP_METHOD_VERSION_CONTROL, "VERSION-CONTROL" }, \
+ { HTTP_METHOD_REPORT, "REPORT" }, \
+ { HTTP_METHOD_CHECKOUT, "CHECKOUT" }, \
+ { HTTP_METHOD_CHECKIN, "CHECKIN" }, \
+ { HTTP_METHOD_UNCHECKOUT, "UNCHECKOUT" }, \
+ { HTTP_METHOD_MKWORKSPACE, "MKWORKSPACE" }, \
+ { HTTP_METHOD_UPDATE, "UPDATE" }, \
+ { HTTP_METHOD_LABEL, "LABEL" }, \
+ { HTTP_METHOD_MERGE, "MERGE" }, \
+ { HTTP_METHOD_BASELINE_CONTROL, "BASELINE-CONTROL" }, \
+ { HTTP_METHOD_MKACTIVITY, "MKACTIVITY" }, \
+ { HTTP_METHOD_ORDERPATCH, "ORDERPATCH" }, \
+ { HTTP_METHOD_ACL, "ACL" }, \
+ { HTTP_METHOD_MKREDIRECTREF, "MKREDIRECTREF" }, \
+ { HTTP_METHOD_UPDATEREDIRECTREF, "UPDATEREDIRECTREF" }, \
+ { HTTP_METHOD_SEARCH, "SEARCH" }, \
{ HTTP_METHOD_PATCH, "PATCH" }, \
{ HTTP_METHOD_NONE, NULL } \
}
@@ -130,7 +172,8 @@ struct http_error {
{ 415, "Unsupported Media Type" }, \
{ 416, "Range Not Satisfiable" }, \
{ 417, "Expectation Failed" }, \
- /* 418-421 unassigned */ \
+ { 418, "I'm a teapot" }, \
+ /* 419-421 unassigned */ \
{ 420, "Enhance Your Calm" }, \
{ 422, "Unprocessable Entity" }, \
{ 423, "Locked" }, \
@@ -142,7 +185,9 @@ struct http_error {
{ 429, "Too Many Requests" }, \
/* 430 unassigned */ \
{ 431, "Request Header Fields Too Large" }, \
- /* 432-499 unassigned */ \
+ /* 432-450 unassigned */ \
+ { 451, "Unavailable For Legal Reasons" }, \
+ /* 452-499 unassigned */ \
{ 500, "Internal Server Error" }, \
{ 501, "Not Implemented" }, \
{ 502, "Bad Gateway" }, \
@@ -176,6 +221,7 @@ struct http_mediatype {
{ "jpeg", "image", "jpeg" }, \
{ "jpg", "image", "jpeg" }, \
{ "png", "image", "png" }, \
+ { "svg", "image", "svg+xml" }, \
{ "js", "application", "javascript" }, \
{ NULL } \
}
@@ -191,9 +237,13 @@ struct http_descriptor {
#define query_key http_matchquery.kv_key
#define query_val http_matchquery.kv_value

+ char *http_host;
enum httpmethod http_method;
int http_chunked;
char *http_version;
+
+ /* Rewritten path remains NULL if not used */
+ char *http_path_alias;

/* A tree of headers and attached lists for repeated headers. */
struct kv *http_lastheader;
Index: usr.sbin/relayd/relay_http.c
===================================================================
RCS file: /cvs/src/usr.sbin/relayd/relay_http.c,v
retrieving revision 1.57
diff -u -p -u -p -r1.57 relay_http.c
--- usr.sbin/relayd/relay_http.c 27 Jul 2016 06:55:44 -0000 1.57
+++ usr.sbin/relayd/relay_http.c 27 Jul 2016 09:36:36 -0000
@@ -402,12 +402,37 @@ relay_read_http(struct bufferevent *bev,
case HTTP_METHOD_GET:
case HTTP_METHOD_HEAD:
case HTTP_METHOD_OPTIONS:
+ /* WebDAV methods */
+ case HTTP_METHOD_COPY:
+ case HTTP_METHOD_MOVE:
cre->toread = 0;
break;
- case HTTP_METHOD_PATCH:
case HTTP_METHOD_POST:
case HTTP_METHOD_PUT:
case HTTP_METHOD_RESPONSE:
+ /* WebDAV methods */
+ case HTTP_METHOD_PROPFIND:
+ case HTTP_METHOD_PROPPATCH:
+ case HTTP_METHOD_MKCOL:
+ case HTTP_METHOD_LOCK:
+ case HTTP_METHOD_UNLOCK:
+ case HTTP_METHOD_VERSION_CONTROL:
+ case HTTP_METHOD_REPORT:
+ case HTTP_METHOD_CHECKOUT:
+ case HTTP_METHOD_CHECKIN:
+ case HTTP_METHOD_UNCHECKOUT:
+ case HTTP_METHOD_MKWORKSPACE:
+ case HTTP_METHOD_UPDATE:
+ case HTTP_METHOD_LABEL:
+ case HTTP_METHOD_MERGE:
+ case HTTP_METHOD_BASELINE_CONTROL:
+ case HTTP_METHOD_MKACTIVITY:
+ case HTTP_METHOD_ORDERPATCH:
+ case HTTP_METHOD_ACL:
+ case HTTP_METHOD_MKREDIRECTREF:
+ case HTTP_METHOD_UPDATEREDIRECTREF:
+ case HTTP_METHOD_SEARCH:
+ case HTTP_METHOD_PATCH:
/* HTTP request payload */
if (cre->toread > 0)
bev->readcb = relay_read_httpcontent;
Index: usr.sbin/relayd/relayd.conf.5
===================================================================
RCS file: /cvs/src/usr.sbin/relayd/relayd.conf.5,v
retrieving revision 1.168
diff -u -p -u -p -r1.168 relayd.conf.5
--- usr.sbin/relayd/relayd.conf.5 6 Nov 2015 18:06:29 -0000 1.168
+++ usr.sbin/relayd/relayd.conf.5 27 Jul 2016 09:36:36 -0000
@@ -1125,23 +1125,39 @@ Match the HTTP request method.

The method is specified by

.Ar name
and can be either
+.Ic ACL ,
+.Ic BASELINE-CONTROL ,
+.Ic CHECKIN ,
+.Ic CHECKOUT ,
.Ic CONNECT ,
.Ic COPY ,
.Ic DELETE ,
.Ic GET ,
.Ic HEAD ,
+.Ic LABEL ,
.Ic LOCK ,
+.Ic MERGE ,
+.Ic MKACTIVITY ,
.Ic MKCOL ,
+.Ic MKREDIRECTREF ,
+.Ic MKWORKSPACE ,
.Ic MOVE ,
.Ic OPTIONS ,
+.Ic ORDERPATCH ,
.Ic PATCH ,
.Ic POST ,
.Ic PROPFIND ,
.Ic PROPPATCH ,
.Ic PUT ,
+.Ic REPORT ,
+.Ic SEARCH ,
.Ic TRACE ,
+.Ic UNCHECKOUT ,
+.Ic UNLOCK ,
+.Ic UPDATE ,
+.Ic UPDATEREDIRECTREF ,
or
-.Ic UNLOCK .
+.Ic VERSION-CONTROL .
.It Xo
.Ar type Ar option
.Oo Oo Ic digest Oc

[Paul Fariello]

On Wed, Jul 27, 2016 at 11:26:28AM +0200, Paul Fariello wrote:
> On Wed, Jul 27, 2016 at 11:08:17AM +0200, Michael Lechtermann wrote:
> >
> > > On 27Juli, 2016, at 10:19, Paul Fariello <pa...@fariello.eu> wrote:
> > >
> > > relayd logs and svn server log could really help.
> > >
> > > I can't reproduce it since I don't have a working svn server.
> >
> > relayd doesn’t print out anything in regards to this, even when using -d and multiple -v
> >
> > Apache also doesn’t recognize any incoming requests (from relayd), so no logs from that either.
> >
>
> Can you check if the http OPTIONS request has a body ? With tcpdump for
> example.
>
> Relayd considers it should not have one. But this kind of behavior
> reminds me the issue I had with CalDav.

Looking at RFC3253, 6.4.1 Example - OPTIONS, it seems that OPTIONS
method can have a body.

Could you try the attached patch ? It remove some logic on http request
size in regards to http methods.

[Reyk Floeter]

> <relayd-remove-superfluous-http-method-logic.patch>

What are you trying to do - removing this logic is obviously not how it was intended.
I think you shouldn't send superfluous diffs.

The OPTIONS request doesn't have a body, but the OPTIONS response may have one.
And there is the difference to httpd - relayd has to handle both sides.

So a proper fix would be to handle the methods for request and response differently -
the webdav diff that I sent before is only part of the fix.

Reyk

[Michael Lechtermann]

> I once added the well-known webdav methods to httpd, the attached diff
> syncs it to relayd. Could you give it a try?

Thanks Reyk, looks like something isn’t right there…

# patch -p0 < 1.patch
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--------------------------

|Index: usr.sbin/relayd/http.h
|===================================================================
|RCS file: /cvs/src/usr.sbin/relayd/http.h,v
|retrieving revision 1.7
|diff -u -p -u -p -r1.7 http.h
|--- usr.sbin/relayd/http.h 11 Jun 2015 18:49:09 -0000 1.7
|+++ usr.sbin/relayd/http.h 27 Jul 2016 09:36:35 -0000

--------------------------
Patching file usr.sbin/relayd/http.h using Plan A...
patch: **** malformed patch at line 12: /*

# pwd
/usr/src

[Paul Fariello]

On Wed, Jul 27, 2016 at 12:18:06PM +0200, Reyk Floeter wrote:
>
> What are you trying to do - removing this logic is obviously not how it was intended.
> I think you shouldn't send superfluous diffs.

I'm just trying to help. Maybe it's the wrong mailing list for such mail
exchanges. Should I post it somewhere else ?

>
> The OPTIONS request doesn't have a body, but the OPTIONS response may have one.

As I said RFC3253 seems to change the behavior of OPTIONS. See 6.4.1
Example - OPTIONS:

>>REQUEST

OPTIONS /doc HTTP/1.1
Host: www.webdav.org
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx

<?xml version="1.0" encoding="utf-8" ?>
<D:options xmlns:D="DAV:">
<D:version-history-collection-set/>
<D:workspace-collection-set/>
</D:options>

>>RESPONSE

HTTP/1.1 200 OK
DAV: 1
DAV: version-control,checkout-in-place,version-history,workspace
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx

<?xml version="1.0" encoding="utf-8" ?>
<D:options-response xmlns:D="DAV:">
<D:version-history-collection-set>
<D:href>http://repo.webdav.org/his</D:href>
</D:version-history-collection-set>
<D:workspace-collection-set>
<D:href>http://www.webdav.org/public/ws</D:href>
<D:href>http://www.webdav.org/private/ws</D:href>
</D:workspace-collection-set>
</D:options-response>

As far as I understand RFC2616 chapter 4.3. one should only consider
Content-Length or Transfer-Encoding for signaling the presence of a
body. IIUC it's what the default does in the switch(desc->http_method).

RFC2616 also states that a server should read and forward a message-body
on any request.

I think it makes it easier for relayd to just ignore whether an http
method is defined to have a body and just use Content-Length. This way
relayd can easily support some http extension.

It's what my patch intended to do.

> And there is the difference to httpd - relayd has to handle both sides.
>
> So a proper fix would be to handle the methods for request and response differently -
> the webdav diff that I sent before is only part of the fix.

Sorry, I missed your patch.

[Michael Lechtermann]

> On 27Juli, 2016, at 12:26, Reyk Floeter <re...@openbsd.org> wrote:
>
> better?

Yes, I could apply the patch now, however I had to make one additional change. Now SVN appears to be working again.

# diff -u relay_http.c.orig relay_http.c
--- relay_http.c.orig Wed Jul 27 10:43:22 2016
+++ relay_http.c Wed Jul 27 10:43:54 2016
@@ -376,12 +376,12 @@
case HTTP_METHOD_DELETE:
case HTTP_METHOD_GET:
case HTTP_METHOD_HEAD:
- case HTTP_METHOD_OPTIONS:
/* WebDAV methods */
case HTTP_METHOD_COPY:

case HTTP_METHOD_MOVE:
cre->toread = 0;
break;

+ case HTTP_METHOD_OPTIONS:

[Reyk Floeter]

Great, yes, this OPTIONS change is correct.

Background: OPTIONS didn't have a body in the past, but RFC 7231 mentions that it may have one for "future extensions". So the future is here…

btw., even Wikipedia interpreted it incorrectly as "No", I fixed it to "Optional":
https://en.wikipedia.org/w/index.php?title=Hypertext_Transfer_Protocol&stable=0#Summary_table

Reyk

[Reyk Floeter]

On Wed, Jul 27, 2016 at 12:46:56PM +0200, Michael Lechtermann wrote:
>
> > On 27Juli, 2016, at 12:26, Reyk Floeter <re...@openbsd.org> wrote:
> >
> > better?
>
> Yes, I could apply the patch now, however I had to make one additional change. Now SVN appears to be working again.
>
> # diff -u relay_http.c.orig relay_http.c
> --- relay_http.c.orig Wed Jul 27 10:43:22 2016
> +++ relay_http.c Wed Jul 27 10:43:54 2016
> @@ -376,12 +376,12 @@
> case HTTP_METHOD_DELETE:
> case HTTP_METHOD_GET:
> case HTTP_METHOD_HEAD:
> - case HTTP_METHOD_OPTIONS:
> /* WebDAV methods */
> case HTTP_METHOD_COPY:
> case HTTP_METHOD_MOVE:
> cre->toread = 0;
> break;
> + case HTTP_METHOD_OPTIONS:
> case HTTP_METHOD_POST:
> case HTTP_METHOD_PUT:
> case HTTP_METHOD_RESPONSE:

I committed the OPTIONS diff first, also in httpd, here is the updated
webdav fix.

For reference.

Reyk

Index: usr.sbin/relayd/http.h
===================================================================
RCS file: /cvs/src/usr.sbin/relayd/http.h,v
retrieving revision 1.7
diff -u -p -u -p -r1.7 http.h
--- usr.sbin/relayd/http.h 11 Jun 2015 18:49:09 -0000 1.7

+++ usr.sbin/relayd/http.h 27 Jul 2016 11:04:48 -0000

retrieving revision 1.58
diff -u -p -u -p -r1.58 relay_http.c
--- usr.sbin/relayd/relay_http.c 27 Jul 2016 11:02:41 -0000 1.58
+++ usr.sbin/relayd/relay_http.c 27 Jul 2016 11:04:48 -0000
@@ -401,13 +401,38 @@ relay_read_http(struct bufferevent *bev,

case HTTP_METHOD_DELETE:
case HTTP_METHOD_GET:
case HTTP_METHOD_HEAD:

+ /* WebDAV methods */
+ case HTTP_METHOD_COPY:

+ case HTTP_METHOD_MOVE:

cre->toread = 0;
break;

case HTTP_METHOD_OPTIONS:
- case HTTP_METHOD_PATCH:

case HTTP_METHOD_POST:
case HTTP_METHOD_PUT:
case HTTP_METHOD_RESPONSE:

+++ usr.sbin/relayd/relayd.conf.5 27 Jul 2016 11:04:48 -0000

[Reyk Floeter]

> On 27.07.2016, at 12:41, Paul Fariello <pa...@fariello.eu> wrote:
>
> On Wed, Jul 27, 2016 at 12:18:06PM +0200, Reyk Floeter wrote:
>>
>> What are you trying to do - removing this logic is obviously not how it was intended.
>> I think you shouldn't send superfluous diffs.
>
> I'm just trying to help.

fair enough

> Maybe it's the wrong mailing list for such mail
> exchanges. Should I post it somewhere else ?
>

yes, but your diff fixed one thing by throwing something else away.

>>
>> The OPTIONS request doesn't have a body, but the OPTIONS response may have one.
>
> As I said RFC3253 seems to change the behavior of OPTIONS. See 6.4.1
> Example - OPTIONS:
>

OPTIONS has been fixed in relayd and httpd with Michael's diff now.

tldr the OPTIONS body is an optional "future extension".
(btw., please refer to the 723x RFCs for HTTP/1.1 now)

and here I disagree, neither relayd nor httpd are going to let everything through.

you wouldn't use "pfctl -d" to fix your firewall problems, of course.

and, quite frankly, HTTP extensions that introduce new methods are relatively rare.
WebDAV is the only relevant, but horrible, extension that we really have to handle.

so we can deal with them in an explicit way.

Reyk

[Paul Fariello]

On Wed, Jul 27, 2016 at 01:31:28PM +0200, Reyk Floeter wrote:
>
> > On 27.07.2016, at 12:41, Paul Fariello <pa...@fariello.eu> wrote:
> >
> > On Wed, Jul 27, 2016 at 12:18:06PM +0200, Reyk Floeter wrote:
> >>
> >> What are you trying to do - removing this logic is obviously not how it was intended.
> >> I think you shouldn't send superfluous diffs.
> >
> > I'm just trying to help.
>
> fair enough
>
> > Maybe it's the wrong mailing list for such mail
> > exchanges. Should I post it somewhere else ?
> >
>
> yes, but your diff fixed one thing by throwing something else away.

Sure, I should have splitted the diffs.

>
> >>
> >> The OPTIONS request doesn't have a body, but the OPTIONS response may have one.
> >
> > As I said RFC3253 seems to change the behavior of OPTIONS. See 6.4.1
> > Example - OPTIONS:
> >
>
> OPTIONS has been fixed in relayd and httpd with Michael's diff now.

Cool. Is the RFC3253 going to be merged to ?

Ok. I didn't notice that relayd had a security filtering focus. If so,
enforcing presence/absence of body is legit.

>
> you wouldn't use "pfctl -d" to fix your firewall problems, of course.

Obviously not. But only because pf is clearly here for filtering.
I thought relayd main purpose was to relay so removing a simple
filtering wasn't an issue.


Regards,

Paul

[Raul Miller]

On Wed, Jul 27, 2016 at 8:00 AM, Paul Fariello <pa...@fariello.eu> wrote:
> Ok. I didn't notice that relayd had a security filtering focus. If so,
> enforcing presence/absence of body is legit.

Perhaps the security.html page on the openbsd site would interest you?
Did you know, for example, that openbsd has a "Secure by Default"
policy?

Also, it is probably a good idea to read the man page for software you
are working on. For example, relayd has a man page which says:

"Various application level filtering ... options are available for relays."

I could go on, with this kind of reasoning, but I probably should give
you the chance to do some thinking, yourself?

--
Raul

[Paul Fariello]

Hi Raul,

On Wed, Jul 27, 2016 at 09:42:23AM -0400, Raul Miller wrote:
> On Wed, Jul 27, 2016 at 8:00 AM, Paul Fariello <pa...@fariello.eu> wrote:
> > Ok. I didn't notice that relayd had a security filtering focus. If so,
> > enforcing presence/absence of body is legit.
>
> Perhaps the security.html page on the openbsd site would interest you?
> Did you know, for example, that openbsd has a "Secure by Default"
> policy?

This raise an interesting question. Does "Secure by Default" means only
- produce secure software
or does it means
- produce software that not only is secure but secures others part of
the OS

My point of view is that producing secure software is difficult enough.
If one want to really protect external piece of software it should use
dedicated software.

>
> Also, it is probably a good idea to read the man page for software you
> are working on. For example, relayd has a man page which says:
>
> "Various application level filtering ... options are available for relays."

I have obviously read the man page before digging into relayd sources
and RFCs. My understanding of "Various application level filtering" is
that relayd provides ways to filter which connection are allowed and
where they should go. I don't think it means that relayd tries to secure
protocols it relays.

Again, this is only my understanding of relayd man page. I may be wrong.

>
> I could go on, with this kind of reasoning, but I probably should give
> you the chance to do some thinking, yourself?

Its always good to encourage people to think on there own. Thanks.

>
> --
> Raul

[Theo de Raadt]

> On Wed, Jul 27, 2016 at 09:42:23AM -0400, Raul Miller wrote:
> > On Wed, Jul 27, 2016 at 8:00 AM, Paul Fariello <pa...@fariello.eu> wrote:
> > > Ok. I didn't notice that relayd had a security filtering focus. If so,
> > > enforcing presence/absence of body is legit.
> >
> > Perhaps the security.html page on the openbsd site would interest you?
> > Did you know, for example, that openbsd has a "Secure by Default"
> > policy?
>
> This raise an interesting question. Does "Secure by Default" means only
> - produce secure software
> or does it means
> - produce software that not only is secure but secures others part of
> the OS

That raises an interesting question. Can you read something and
understand it as it is, or do you have to insert your biases and views
into it?

> My point of view is that producing secure software is difficult enough.
> If one want to really protect external piece of software it should use
> dedicated software.

Who cares. So write your own software and use it.