Re: Serving multiple domains on one machine or IP address

[Simen Stavdal]

Hi Greg,

I haven't done this myself, but take a look at the man pages of httpd.conf
under the servers sections.
You can create multiple a-records pointing to the same ip address, and then
pick up the incoming traffic by inspecting the http header in order to find
which virtual server to send the traffic.

Simon.

On 19 September 2017 at 07:46, Niels Kobschaetzki 
wrote:

>
> > On 19. Sep 2017, at 07:17, Greg Garrison  wrote:
> >
>
> 
>
> > Additionally I notice that the default client HTTP error messages (e.g.
> 404 error) that HTTPD generates reveal that the server is running OpenBSD.
> This is not a big deal but if the error messages were configurable so that
> they could mask the server OS or could display an otherwise custom message
> I would see value in that. Does this capability exist with without
> recompiling HTTPD?
>
> Being curious: Why do you want to mask the server-OS in the error message?
>
> Niels
>

Re: Serving multiple domains on one machine or IP address

[Niels Kobschaetzki]

> On 19. Sep 2017, at 07:17, Greg Garrison  wrote:
> 



> Additionally I notice that the default client HTTP error messages (e.g. 404 
> error) that HTTPD generates reveal that the server is running OpenBSD. This 
> is not a big deal but if the error messages were configurable so that they 
> could mask the server OS or could display an otherwise custom message I would 
> see value in that. Does this capability exist with without recompiling HTTPD?

Being curious: Why do you want to mask the server-OS in the error message?

Niels

Serving multiple domains on one machine or IP address

[Greg Garrison]

Hi,

I am interested if I can serve multiple domains from one machine using 
HTTPD and possibly VMM and RELAYD. I would prefer if there was a 
solution just with HTTPD is order to KISS. If it is really painful I'll 
just role more servers.


I am running OpenBSD on a VPS. I have 3 to 5 web sites (separate 
domains) that I want to serve. They are all very small traffic at this 
time. I would rather run them on one VPS than each on its own because it 
would be cheaper, until traffic increases. My VPS provider can provide 
three external IP addresses in the form of one + two aliases for a 
single (virtual) machine. Is it possible to configure HTTPD to reply to 
queries for site1 on IP1 and  site2 on IP2 and site3 on IP3, for example.


Additionally I notice that the default client HTTP error messages (e.g. 
404 error) that HTTPD generates reveal that the server is running 
OpenBSD. This is not a big deal but if the error messages were 
configurable so that they could mask the server OS or could display an 
otherwise custom message I would see value in that. Does this capability 
exist with without recompiling HTTPD?


Thanks,

Greg

Vintage O'Reilly Books - OpenBSD Books

[Jay Hart]

Looking to thin my book collection a bit.  I have the following books I'm 
hoping to move to a
better home:

First Set:

1. Learning the Bash Shell, O'Reilly, 1st Edition, Oct 1995.

2. Mastering Regular Expressions, O'Reilly, 1st Edition, Nov 1997 printing

3. Programming Perl, O'Reilly, 2nd Edition, Sept 1996

4. Advanced Perl Programming, O'Reilly, 1st Edition, Aug 1997

5. TCP/IP Network Administration, O'Reilly, 2nd Edition, Jan 1998

I'm looking to get $40 for all five, international shipping extra.

They are in great condition.

Second Set:

1. Building Firewalls with OpenBSD and PF, Devguide.net by Jacek Artymiak , 2nd 
Edition, 2003.
- Book physically intact, but has binding issues.

2. Secure Architectures with OpenBSD, Addison-Wesley, by Jose Nazario and 
Brandon Palmer, First
Printing, April 2004.
- Very Good  Condition.

3. Absolute OpenBSD, Unix for the Practical Paranoid, No Starch, by Michael 
Lucas, 2003.
- Very Good  Condition.

I'm looking to get $25 for the set, international shipping extra.

Buy both sets for $60, plus shipping if international. Books are in USA.  $15 
donation to OpenBSD
foundation if I sell both sets.

Thanks for looking,

Jay

Re: softraid crypto seem really slower than plain ffs

[bofh]

On Mon, Sep 18, 2017 at 11:30 AM, Joel Carnat  wrote:

> Hello,
>
> I was really annoyed by the numbers I got. So I did the testings again.
> Using
> a brand new VM. Being really careful on what I was doing and writing it
> down
> after each command run. I did the testings using 6.1 and 6.2-current, in
> case
> there were some changes. There weren't.
>
> First of all. There isn't 10x difference between PLAIN and ENCRYPTED.
> I believe I have mixed numbers from my various testings. I also believe
> Cloud
> providers don't/can't guarantee throughput on disk. I noticed variations
> from
> 1 to 4 on the same VM between 2 days... whatever the OS was.
>

This is why you *NEVER* run benchmark tests for OS on VMs.  Unless you are
benchmarking the VM system, it's basically worthless.

You spent a lot of time and effort - but the results are pretty much
useless because it cannot be duplicated.

Re: reused group key update received

[Matthias Schmidt]

Hi,

* Matthias Schmidt wrote:
> Hi,
> 
> today I saw the following message in my logs browsing by:
> 
> Sep 18 19:55:17 sigma /bsd: iwm0: reused group key update received from 
> 9c:c7:a6:56:3e:69
> 
> I remembered that this message has been added by stsp@ at August 17th
> and he's interested in seeing this message.  However, the message
> appeared in my private WLAN at home and not in some suspicious open
> WLAN.
> 
> The MAC address is not the one of my local FritzBox but close.  They
> only differ in the last part, my FrizBox has :67 and not :69.

Apparently that statement is wrong.  My router's MAC address indeed ends
with :69, however, the arp -a output shows the wrong MAC:

$ arp -an
Host Ethernet AddressNetif ExpireFlags
172.16.1.1   9c:c7:a6:56:3e:67iwm0 19m56s

Re: OpenBSD's HTTPD troubles AGAIN - Can't find any man page that explains how to properly set up directory authentication.

[tec...@protonmail.com]

Yeah, I'm not great at explaining stuff sometimes - but your spot on.

Regards

> Michael Hekeler  writes:
>
>> Whats wrong with the manpage?
>>
>> [no] authenticate [realm] with htpasswd
>> Authenticate a remote user for realm by checking the
>> credentials against the user authentication file htpasswd.
>> The file name is relative to the chroot and must be
>> readable by the www user. Use the no authenticate directive
>> to disable authentication in a location.
>> Authenticate a remote user for realm by checking the
>> credentials against the user authentication file htpasswd.
>> The file name is relative to the chroot and must be readable
>> by the www user. Use the no authenticate directive to disable
>> authentication in a location.
>>
>>
>>
>>> I read it totally differently, that the htpasswd is a location to a
>>> file and not just a declaration to look for a file in the current dir
>>> named htpasswd etc.
>>
>> The htpasswd IS a file:
>> location "/*" { authenticate with "/htpasswd" }
>>
>> In this example the passwordfile is named "htpasswd" and is in /var/www
>> (Note that httpd(8) is chrooted by default)
>
> I think he meant possible confusion over whether "htpasswd" is the
> literal/only name of the file, or a stand-in name for "any file name I
> choose" e.g. if my password file was named "foo" then the directive
> would be
>
> authenticate [realm] with foo.
>
> I could see it being interpreted that way, anyway.
>
> Allan

Re: OpenBSD's HTTPD troubles AGAIN - Can't find any man page that explains how to properly set up directory authentication.

[tec...@protonmail.com]

Thanks for the reply.  This issue was worked out already thanks to another user 
on the misc board.  I appreciate the info on the RFC, I never looked that up - 
I never even thought to tbh as was just trying to do it from the man page.  
Well, who knows - I just read that section of the man page quite differently - 
a rewritten version from another guy made me understand it properly.  Some man 
pages are just confusing and some are clear and simple, with excellent examples 
to explain something.  Anyway, that is some good info on the realm stuff - I'll 
look into that.

Regards.

> Am Sat, 16 Sep 2017 08:35:59 -0400
> schrieb "tec...@protonmail.com" :
>
>> You are a legend. Got it working with that!
>>
>> Thank you so much, saved me a bigger headache!
>>
>> p.s. Still, looking at the man page that really is not obvious where
>> it mentions [realm] and [htpasswd].
>
> Whats wrong with the manpage?
>
> [no] authenticate [realm] with htpasswd
> Authenticate a remote user for realm by checking the
> credentials against the user authentication file htpasswd.
> The file name is relative to the chroot and must be
> readable by the www user. Use the no authenticate directive
> to disable authentication in a location.
> Authenticate a remote user for realm by checking the
> credentials against the user authentication file htpasswd.
> The file name is relative to the chroot and must be readable
> by the www user. Use the no authenticate directive to disable
> authentication in a location.
>
>> I read it totally differently, that the htpasswd is a location to a
>> file and not just a declaration to look for a file in the current dir
>> named htpasswd etc.
>
> The htpasswd IS a file:
> location "/*" { authenticate with "/htpasswd" }
>
> In this example the passwordfile is named "htpasswd" and is in /var/www
> (Note that httpd(8) is chrooted by default)
>
>> I wonder where did "Secure Area" came from too,
>> "realm" is mentioned but I had not a clue what it even was. I still
>> don"t.
>
> From RFC 1945 (HTTP/1.0) and RFC 2617 (HTTP Authentication referenced
> by HTTP/1.1):
> The realm attribute (case-insensitive) is required for all
> authentication schemes which issue a challenge. The realm value
> (case-sensitive), in combination with the canonical root URL of the
> server being accessed, defines the protection space. These realms allow
> the protected resources on a server to be partitioned into a set of
> protection spaces, each with its own authentication scheme and/or
> authorization database. The realm value is a string, generally assigned
> by the origin server, which may have additional semantics specific to
> the authentication scheme.
>
> In short, pages in the same realm should share credentials. If your
> credentials work for a page with the realm "My Realm", it should be
> assumed that the same username and password combination should work for
> another page with the same realm.
>
>> I cannot stand the man page for httpd.conf - so much
>> frustration for me.
>
> If you have concrete questions then ask.
> My experience is that someone on the list will try to help.
> But by now: ... what is your question?

Re: OpenBSD's HTTPD troubles AGAIN - Can't find any man page that explains how to properly set up directory authentication.

[Allan Streib]

Michael Hekeler  writes:

> Whats wrong with the manpage?
>
>[no] authenticate [realm] with htpasswd 
>Authenticate a remote user for realm by checking the
>credentials against the user authentication file htpasswd.
>The file name is relative to the chroot and must be
>readable by the www user. Use the no authenticate directive
>to disable authentication in a location.
>Authenticate a remote user for realm by checking the
>credentials against the user authentication file htpasswd.
>The file name is relative to the chroot and must be readable
>by the www user. Use the no authenticate directive to disable
>authentication in a location.
>
>
>
>> I read it totally differently, that the htpasswd is a location to a
>> file and not just a declaration to look for a file in the current dir
>> named htpasswd etc.  
>
> The htpasswd IS a file:
>   location "/*" { authenticate with "/htpasswd" }
>
> In this example the passwordfile is named "htpasswd" and is in /var/www
> (Note that httpd(8) is chrooted by default)

I think he meant possible confusion over whether "htpasswd" is the
literal/only name of the file, or a stand-in name for "any file name I
choose" e.g. if my password file was named "foo" then the directive
would be

  authenticate [realm] with foo.

I could see it being interpreted that way, anyway.

Allan

Re: OpenBSD's HTTPD troubles AGAIN - Can't find any man page that explains how to properly set up directory authentication.

[Michael Hekeler]

Am Sat, 16 Sep 2017 08:35:59 -0400
schrieb "tec...@protonmail.com" :

> You are a legend.  Got it working with that!
> 
> Thank you so much, saved me a bigger headache!
> 
> p.s. Still, looking at the man page that really is not obvious where
> it mentions [realm] and [htpasswd].  

Whats wrong with the manpage?

   [no] authenticate [realm] with htpasswd 
   Authenticate a remote user for realm by checking the
   credentials against the user authentication file htpasswd.
   The file name is relative to the chroot and must be
   readable by the www user. Use the no authenticate directive
   to disable authentication in a location.
   Authenticate a remote user for realm by checking the
   credentials against the user authentication file htpasswd.
   The file name is relative to the chroot and must be readable
   by the www user. Use the no authenticate directive to disable
   authentication in a location.



> I read it totally differently, that the htpasswd is a location to a
> file and not just a declaration to look for a file in the current dir
> named htpasswd etc.  

The htpasswd IS a file:
  location "/*" { authenticate with "/htpasswd" }

In this example the passwordfile is named "htpasswd" and is in /var/www
(Note that httpd(8) is chrooted by default)



> I wonder where did "Secure Area" came from too,
> 'realm' is mentioned but I had not a clue what it even was.  I still
> don't.

From RFC 1945 (HTTP/1.0) and RFC 2617 (HTTP Authentication referenced
by HTTP/1.1):
The realm attribute (case-insensitive) is required for all
authentication schemes which issue a challenge. The realm value
(case-sensitive), in combination with the canonical root URL of the
server being accessed, defines the protection space. These realms allow
the protected resources on a server to be partitioned into a set of
protection spaces, each with its own authentication scheme and/or
authorization database. The realm value is a string, generally assigned
by the origin server, which may have additional semantics specific to
the authentication scheme.

In short, pages in the same realm should share credentials. If your
credentials work for a page with the realm "My Realm", it should be
assumed that the same username and password combination should work for
another page with the same realm.



>  I cannot stand the man page for httpd.conf - so much
> frustration for me.

If you have concrete questions then ask.
My experience is that someone on the list will try to help.
But by now: ... what is your question?

reused group key update received

[Matthias Schmidt]

Hi,

today I saw the following message in my logs browsing by:

Sep 18 19:55:17 sigma /bsd: iwm0: reused group key update received from 
9c:c7:a6:56:3e:69

I remembered that this message has been added by stsp@ at August 17th
and he's interested in seeing this message.  However, the message
appeared in my private WLAN at home and not in some suspicious open
WLAN.

The MAC address is not the one of my local FritzBox but close.  They
only differ in the last part, my FrizBox has :67 and not :69.

Anything else I should do?  An arping to the address does not revealed
any results.  Also nothing in my Router-logs.

Cheers

Matthias

Re: softraid crypto seem really slower than plain ffs

[Joel Carnat]

Hello,

I was really annoyed by the numbers I got. So I did the testings again. 
Using
a brand new VM. Being really careful on what I was doing and writing it 
down
after each command run. I did the testings using 6.1 and 6.2-current, in 
case

there were some changes. There weren't.

First of all. There isn't 10x difference between PLAIN and ENCRYPTED.
I believe I have mixed numbers from my various testings. I also believe 
Cloud
providers don't/can't guarantee throughput on disk. I noticed variations 
from

1 to 4 on the same VM between 2 days... whatever the OS was.

In the end, there only seem to be a 1.5 factor difference between PLAIN 
and
ENCRYPTED. And according to iostat, what happens is that when writing on 
the
encrypted partition (sd1a), io already happen on the plain partition 
(sd0a).

# disklabel sd0
(...)
  a: 52420031   64RAID
  c: 524288000  unused
# disklabel sd1
(...)
  a: 48194944  4209056  4.2BSD   2048 16384 12958 # /
  b:  4208966   64swap# none
  c: 524195030  unused
# iostat -w 1 sd0 sd1
  tty  sd0   sd1 cpu
 tin tout  KB/t  t/s  MB/s   KB/t  t/s  MB/s  us ni sy in id
   0   61 16.00 5180 80.94  16.00 5180 80.94   1  0 91  8  0
   0  184 16.00 4594 71.78  16.00 4594 71.78   0  0 95  5  0
   0   61 16.00 5126 80.09  16.00 5126 80.09   1  0 95  4  0
   0   61 16.00 5014 78.34  16.00 5012 78.31   0  0 94  6  0
(...)

Regards.

Le 18/09/2017 09:40, Stefan Sperling a écrit :

On Sun, Sep 17, 2017 at 07:32:49PM +0100, Kevin Chadwick wrote:

I'm not a developer but I know 6.1 moved to a shiny new side channel
resistant AES. I seem to remember Theo saying that if it is that slow
then even worse; people won't use encryption at all and if they need
side channel resistance then they could get a processor with AES-NI
etc.. Not sure if it was reverted in the end or not.


It was reverted.

Problem IPSEC phase 2

[Christiano Liberato]

Hi,

I've been trying for days to close a tunnel with a client and I can not.
Logs always appear:

message_recv: cleartext phase 2 message
dropped message from ipcliente port 500 due to notification type
INVALID_FLAGS
transport_send_messages: giving up on exchange peer-ipcliente, no response
from peer ipcliente:500

I've been looking for a lot on the internet and so far no solution. Just
ask to restart the tunnel on both sides.
On my side, I use openbsd 6.1.
Has anyone seen this error?

Thanks!!

Re: softraid crypto seem really slower than plain ffs

[Stefan Sperling]

On Sun, Sep 17, 2017 at 07:32:49PM +0100, Kevin Chadwick wrote:
> I'm not a developer but I know 6.1 moved to a shiny new side channel 
> resistant AES. I seem to remember Theo saying that if it is that slow
> then even worse; people won't use encryption at all and if they need
> side channel resistance then they could get a processor with AES-NI
> etc.. Not sure if it was reverted in the end or not.
 
It was reverted.

Re: 6.1-stable: kernel panic on pf_state_key_unref()

[Mathieu BLANC]

Le 07/09/2017 à 05:59, Maxim Bourmistrov a écrit :

Hey,
Got kernel panic on 6.1-stable during ’rcctl restart relayd’.

Sorry for PNG below.




Hi,

It has been fixed with this diff :
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf.c.diff?r1=1.1034=1.1035

Re: [PATCH] ure improvement

[sc dying]

On 2017/09/18 03:44, ti...@openmailbox.org wrote:
> Hi SC,
>
> Thanks for committing!
>
> Should this patch probably fix the many terrible issues AXEN has been 
> documented to have recently?

This patch is for URE, not AXEN.

>
> (Lazy question, was this patch included in the 6.1 snapshot)

AFAICS the patch is commited on Jul 20.

>
> Tinker
>
>> Hi,
>>
>> This patch does:
>>
>> - Enable RX aggregation.
>> - Fix RX packet buffer alignment, using roundup() macro in sys/params.h.
>> - Call usbd_set_config before configuring endpoints in ure_init to fix
>>an error when re-opening pipes.  I grabbed the code from if_kue.c.
>> - Make the chip recognize given MAC address.
>> - Remove ure_reset in ure_init, becasue its already called from ure_stop.
>>
>> Regards,
>>
>> --- sys/dev/usb/if_ure.c Wed May  3 22:20:15 2017
>> +++ sys/dev/usb/if_ure.c Mon Jun 19 09:11:09 2017
[...]