Re: httpd incorrectly handles OCSP stapling

2017-08-29 Thread lists+bugs
On Mon, Aug 14, 2017 at 08:00:11AM +0200, Andreas Bartelt wrote:
> On 08/13/17 08:50, Joel Sing wrote:
> > On Friday 11 August 2017 03:31:27 lists+b...@ggp2.com wrote:
> ...
> > 
> > This should already be fixed in -current.
> > 
> 
> I've just tested OCSP stapling via httpd with multiple domains on current
> (all domains also resolve to the same IP address in this setup). I'm
> observing the same problem, i.e., OCSP stapling only works for the first
> domain which has been defined in httpd.conf.

I just confirmed on the latest snapshot (with the ALPN fix) that OCSP is
still broken for multiple domains.  I have 2 domains test1.ggp2.com and
test2.ggp2.com.  Whichever domain defines the OCSP certificate first
works fine.

eg

server "test1.ggp2.com" {
ocsp...
}
server "test2.ggp2.com" {
ocsp...
}

Then test1.ggp2.com works, and if 

server "test2.ggp2.com" {
ocsp...
}
server "test1.ggp2.com" {
ocsp...
}

then test2.ggp2.com works.

The error firefox gives is:

MOZILLA_PKIX_ERROR_OCSP_RESPONSE_FOR_CERT_MISSING, which is different
than I was seeing before.  Chrome now works, and ssl labs reports
"Invalid   No response provided".



httpd.conf is as follows:

ext_addr="*"

server "default" {
listen on $ext_addr port 80

block return 302 "https://test1.ggp2.com$REQUEST_URI";
}

server "test1.ggp2.com" {
listen on $ext_addr port 80
alias "test2.ggp2.com"

block return 301 "https://$SERVER_NAME$REQUEST_URI";
}

server "test1.ggp2.com" {
listen on $ext_addr tls port 443

hsts {
subdomains
preload
}

tls {
certificate "/etc/ssl/acme/test1.ggp2.com.fullchain.pem"
key "/etc/ssl/acme/private/test1.ggp2.com.key"
ocsp "/etc/ssl/acme/test1.ggp2.com.der"
}

location "/.well-known/acme-challenge/*" {
root "/acme"
root strip 2
}
}

server "test2.ggp2.com" {
listen on $ext_addr tls port 443

hsts {
subdomains
preload
}

tls {
certificate "/etc/ssl/acme/test2.ggp2.com.fullchain.pem"
key "/etc/ssl/acme/private/test2.ggp2.com.key"
ocsp "/etc/ssl/acme/test2.ggp2.com.der"
}

location "/.well-known/acme-challenge/*" {
root "/acme"
root strip 2
}
}



Re: httpd incorrectly handles OCSP stapling

2017-08-13 Thread Andreas Bartelt

On 08/13/17 08:50, Joel Sing wrote:

On Friday 11 August 2017 03:31:27 lists+b...@ggp2.com wrote:

...


This should already be fixed in -current.



I've just tested OCSP stapling via httpd with multiple domains on 
current (all domains also resolve to the same IP address in this setup). 
I'm observing the same problem, i.e., OCSP stapling only works for the 
first domain which has been defined in httpd.conf.




Re: httpd incorrectly handles OCSP stapling

2017-08-13 Thread lists+bugs
On Sun, Aug 13, 2017 at 04:50:11PM +1000, Joel Sing wrote:
> This should already be fixed in -current.

Thanks, Joel.  I'll get some test domains up one one of my -current
systems to confirm.  I don't have any exposed at the moment, and combed
through the CVS logs to see if anything obvious had been committed
before posting the bug (although I obviously missed it).



Re: httpd incorrectly handles OCSP stapling

2017-08-12 Thread Joel Sing
On Friday 11 August 2017 03:31:27 lists+b...@ggp2.com wrote:
> >Synopsis:  httpd incorrectly handles OCSP stapling 
> >Category:  system
> 
> >Environment:
> System  : OpenBSD 6.1
> Details : OpenBSD 6.1 (GENERIC.MP) #19: Thu Aug  3 14:59:44 CEST
> 2017
> rob...@syspatch-61-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERI
> C.MP
> 
> Architecture: OpenBSD.amd64
> Machine : amd64
> 
> >Description:
> I run multiple domains on an httpd instance.  When I tried to enable
> OCSP stapling for several domains, only the first defined domain would work
> properly.  Regardless of whether I had defined an OCSP block or not for
> subsequent domains after the first, I'm suspecting that the OCSP response
> stapled to the first domain is used for all the others.  Firefox refuses to
> connect to any but the first defined domains, and gives an OCSP error.
> 
> (also apologies if this is a repost, I didn't have the alias set up
> yet,  and believe the majordomo "confirm" mail went to /dev/null)
> 
> >How-To-Repeat:
> Get OCSP responses:
> 
> ocspcheck -N -o /etc/ssl/acme/domain1.com.der
> /etc/ssl/acme/domain1.com.fullchain.pem ocspcheck -N -o
> /etc/ssl/acme/domain2.com.der /etc/ssl/acme/domain2.com.fullchain.pem 
> Define multiple server{} blocks in httpd.conf, and give each an ocsp
> defintion: 
> server "domain1.com" {
> listen on $ext_addr tls port 443
> 
> tls {
> certificate "/etc/ssl/acme/domain1.com.fullchain.pem"
> key "/etc/ssl/acme/private/domain1.com.key"
> ocsp "/etc/ssl/acme/domain1.com.der"
> }
> }
> 
> server "domain2.com" {
> listen on $ext_addr tls port 443
> 
> tls {
> certificate "/etc/ssl/acme/domain2.com.fullchain.pem"
> key "/etc/ssl/acme/private/domain2.com.key"
> ocsp "/etc/ssl/acme/domain2.com.der"
> }
> }
> 
> Try to visit domain2.com.  Whether or not domain2 has the ocsp
> definition is irrelevant; Firefox fails to access the domain with an OCSP
> error.  domain1.com works fine in either case.
> 
> >Fix:
> Fix is unknown, but would involve OCSP stapling being handled properly
> for multiple domains.  It could be SNI related.

This should already be fixed in -current.



httpd incorrectly handles OCSP stapling

2017-08-10 Thread lists+bugs
>Synopsis:      httpd incorrectly handles OCSP stapling 
>Category:  system
>Environment:
System  : OpenBSD 6.1
Details : OpenBSD 6.1 (GENERIC.MP) #19: Thu Aug  3 14:59:44 CEST 
2017
 
rob...@syspatch-61-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64
>Description:
I run multiple domains on an httpd instance.  When I tried to enable OCSP
stapling for several domains, only the first defined domain would work
properly.  Regardless of whether I had defined an OCSP block or not for
subsequent domains after the first, I'm suspecting that the OCSP response
stapled to the first domain is used for all the others.  Firefox refuses to
connect to any but the first defined domains, and gives an OCSP error.

(also apologies if this is a repost, I didn't have the alias set up yet, 
 and believe the majordomo "confirm" mail went to /dev/null)
>How-To-Repeat:
Get OCSP responses:

ocspcheck -N -o /etc/ssl/acme/domain1.com.der 
/etc/ssl/acme/domain1.com.fullchain.pem
ocspcheck -N -o /etc/ssl/acme/domain2.com.der 
/etc/ssl/acme/domain2.com.fullchain.pem

Define multiple server{} blocks in httpd.conf, and give each an ocsp 
defintion:

server "domain1.com" {
listen on $ext_addr tls port 443

tls {
certificate "/etc/ssl/acme/domain1.com.fullchain.pem"
key "/etc/ssl/acme/private/domain1.com.key"
ocsp "/etc/ssl/acme/domain1.com.der"
}
}

server "domain2.com" {
listen on $ext_addr tls port 443

tls {
certificate "/etc/ssl/acme/domain2.com.fullchain.pem"
key "/etc/ssl/acme/private/domain2.com.key"
ocsp "/etc/ssl/acme/domain2.com.der"
}
}

Try to visit domain2.com.  Whether or not domain2 has the ocsp definition is
irrelevant; Firefox fails to access the domain with an OCSP error.  
domain1.com
works fine in either case.
>Fix:
Fix is unknown, but would involve OCSP stapling being handled properly for
multiple domains.  It could be SNI related.


dmesg:
OpenBSD 6.1 (GENERIC.MP) #19: Thu Aug  3 14:59:44 CEST 2017

rob...@syspatch-61-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4141355008 (3949MB)
avail mem = 4011163648 (3825MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf0100 (53 entries)
bios0: vendor Award Software International, Inc. version "F7" date 11/30/2009
bios0: Gigabyte Technology Co., Ltd. GA-MA785GM-US2H
acpi0 at bios0: rev 0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET MCFG TAMG APIC
acpi0: wakeup devices USB0(S3) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) 
USB6(S3) SBAZ(S4) P2P_(S5) PCE2(S4) PCE3(S4) PCE4(S4) PCE5(S4) PCE6(S4) 
PCE7(S4) PCE9(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpihpet0 at acpi0: 14318180 Hz
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Athlon(tm) II X2 270 Processor, 3415.82 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,ITSC
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB 64b/line 
16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative
cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative
cpu0: AMD erratum 721 detected and fixed
cpu0: TSC frequency 3415823080 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 200MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD Athlon(tm) II X2 270 Processor, 3415.46 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,ITSC
cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB 64b/line 
16-way L2 cache
cpu1: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative
cpu1: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative
cpu1: AMD erratum 721 detected and fixed
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 3 (P2P_)
acpiprt2 at acpi0: bus -1 (PCE2)
acpiprt3 at acpi0: bus -1 (PCE3)
acpiprt4 at acpi0: bus -1 (PCE4)
ac