Re: Allow install from https server w/ self signed cert

[RD Thrush]

On 01/06/17 06:28, Stuart Henderson wrote:
> Related to this (and particularly thinking about autoinstalls),
> would it make sense to allow explicit protocols in the hostname?
> 
> some.host -> https with http fallback
> http://some.host/ -> http only
> https://some.host/ -> https only, no fallback

Many thanks to rpe@ for this fix. install.sub v1.943 works perfectly with my 
legacy nas and its self-signed cert.

Re: Allow install from https server w/ self signed cert

[Theo de Raadt]

> On Sat, Jan 07, 2017 at 03:52:04PM -0700, Theo de Raadt wrote:
> > > What workarounds would be reasonable and approriate? and does it
> > > make sense for OpenBSD to support such scenarios out-of-the-box to
> > > promote wider adoption of better software?
> > 
> > If you want buy the OpenBSD-installer-for-drones, contact me offline.
> > That featureset didn't make it into the free software version.
> 
> 
> But out GeoLocation shit in the installer will just find that it's
> located on a netblock that is registered 5000 feet over Pakistan and
> direct it to a local public mirror!  Definately have to disable
> that feature from the free software version.

https://en.wikipedia.org/wiki/Iran%E2%80%93U.S._RQ-170_incident

Re: Allow install from https server w/ self signed cert

[Bob Beck]

On Sat, Jan 07, 2017 at 03:52:04PM -0700, Theo de Raadt wrote:
> > What workarounds would be reasonable and approriate? and does it
> > make sense for OpenBSD to support such scenarios out-of-the-box to
> > promote wider adoption of better software?
> 
> If you want buy the OpenBSD-installer-for-drones, contact me offline.
> That featureset didn't make it into the free software version.


But out GeoLocation shit in the installer will just find that it's
located on a netblock that is registered 5000 feet over Pakistan and
direct it to a local public mirror!  Definately have to disable
that feature from the free software version.

Re: Allow install from https server w/ self signed cert

[Theo de Raadt]

> What workarounds would be reasonable and approriate? and does it
> make sense for OpenBSD to support such scenarios out-of-the-box to
> promote wider adoption of better software?

If you want buy the OpenBSD-installer-for-drones, contact me offline.
That featureset didn't make it into the free software version.

Re: Allow install from https server w/ self signed cert

[Theo de Raadt]

> > And we should also ask a firmware question?
> > 
> > Nope.  I don't think we should bend over backwards for people doing
> > strange things.  They are on their own.
> > 
> 
> Most of the time I agree with this particular attitude and it is indeed 
> appropriate for the OP case. However, there some major networks such as 
> various governments (or for example .mil) that do not participate in 
> the public PKI but run their own PKI infrastructure. What effect will 
> the installer's checks have in that environment? What workarounds would 
> be reasonable and approriate? and does it make sense for OpenBSD to 
> support such scenarios out-of-the-box to promote wider adoption of 
> better software?

The installer falls back to http.

Just like it worked in 6.0 and all previous releases.

So there is no problem.  If you don't participate in the publically
available cert model for https, it asks for a question and you fall
back to http and continue on.

We are following the same roadmap the browsers followed.

Let me point out that our install script caters poorly to the Zulu
speaking population.  Also to the french.

Not all minority featuresets can be supported.  Please stop dismissing
20 years of effort to create an install media which supports so many
many usage cases -- by insisting on the addition of more usage cases.
It is amazing so much good and complex behaviours come out of such a
small package; those who have dug into the guts of the install media
understand.

Essentially, you are making an enemy of good argument.

And frankly, you say .mil?  Good grief, that's unacceptable, our stuff
is post-FIPS.

Re: Allow install from https server w/ self signed cert

[Bob Beck]

On Sat, Jan 07, 2017 at 05:42:24PM -0500, Jacob L. Leifman wrote:

> Most of the time I agree with this particular attitude and it is indeed 
> appropriate for the OP case. However, there some major networks such as 
> various governments (or for example .mil) that do not participate in 
> the public PKI but run their own PKI infrastructure. What effect will 
> the installer's checks have in that environment? What workarounds would 
> be reasonable and approriate? and does it make sense for OpenBSD to 
> support such scenarios out-of-the-box to promote wider adoption of 
> better software?

That's not a good reason, since in the case of what I am describing they
would *still be depending on the public PKI infrastrucure* to publish
their own list of signers..  No.. they aren't going to do that.. Sorry, 
Unless you're mailing me from a .mil address I think you might
be imagining this usage case. 

they're probably building from source, or have the wherewithall to roll
their own bsd.rd if they care about doing this. 

Re: Allow install from https server w/ self signed cert

[Jacob L. Leifman]

On 7 Jan 2017 at 15:28, Theo de Raadt wrote:

> > On Fri, Jan 06, 2017 at 10:48:37AM -0500, RD Thrush wrote:
> > > On 01/06/17 06:28, Stuart Henderson wrote:
> > > > Related to this (and particularly thinking about autoinstalls),
> > > > would it make sense to allow explicit protocols in the hostname?
> > > > 
> > > > some.host -> https with http fallback
> > > > http://some.host/ -> http only
> > > > https://some.host/ -> https only, no fallback
> > > 
> > > That would totally work for my install problem.
> > > 
> > > FWIW, instead of running a patched install.sub, "rm
> > > /etc/ssl/cert.pem" makes the install bypass the https attempt.
> > > 
> > 
> > Note, if you're upgrading or otherwise have a way to et a cert.pem
> > bundle onto there to *replace* the default, you could always drop the
> > signer for your private self-signed server into the cert.pem bundle,
> > at which point it would be accepted as trusted. 
> > 
> > of course if you're just installing you have an interesting chicken
> > and egg problem, unless you put it somewhere on an https site that
> > does have a real certificate, drop out of the installer and do
> > 
> > ftp -o /tmp/mysigner.pem https://my.secure.site/mysigner.pem
> > cat /tmp/mysigner.pem >> /etc/ssl/cert.pem
> > 
> > then continue the install, and you're good. 
> > 
> > Almost wonder if it's worth an extra question in the installer to ask
> > for an https address to retrieve a certficiate bundle to be appended
> > to cert.pem for the install...
> 
> And we should also ask a firmware question?
> 
> Nope.  I don't think we should bend over backwards for people doing
> strange things.  They are on their own.
> 

Most of the time I agree with this particular attitude and it is indeed 
appropriate for the OP case. However, there some major networks such as 
various governments (or for example .mil) that do not participate in 
the public PKI but run their own PKI infrastructure. What effect will 
the installer's checks have in that environment? What workarounds would 
be reasonable and approriate? and does it make sense for OpenBSD to 
support such scenarios out-of-the-box to promote wider adoption of 
better software?

Re: Allow install from https server w/ self signed cert

[Theo de Raadt]

> On Fri, Jan 06, 2017 at 10:48:37AM -0500, RD Thrush wrote:
> > On 01/06/17 06:28, Stuart Henderson wrote:
> > > Related to this (and particularly thinking about autoinstalls),
> > > would it make sense to allow explicit protocols in the hostname?
> > > 
> > > some.host -> https with http fallback
> > > http://some.host/ -> http only
> > > https://some.host/ -> https only, no fallback
> > 
> > That would totally work for my install problem.
> > 
> > FWIW, instead of running a patched install.sub, "rm /etc/ssl/cert.pem" 
> > makes the install bypass the https attempt.
> > 
> 
> Note, if you're upgrading or otherwise have a way to et a cert.pem bundle 
> onto there to *replace*
> the default, you could always drop the signer for your private self-signed 
> server into the cert.pem
> bundle, at which point it would be accepted as trusted. 
> 
> of course if you're just installing you have an interesting chicken and egg 
> problem, unless
> you put it somewhere on an https site that does have a real certificate, drop 
> out of the
> installer and do
> 
> ftp -o /tmp/mysigner.pem https://my.secure.site/mysigner.pem
> cat /tmp/mysigner.pem >> /etc/ssl/cert.pem
> 
> then continue the install, and you're good. 
> 
> Almost wonder if it's worth an extra question in the installer to ask
> for an https address to retrieve a certficiate bundle to be appended to 
> cert.pem
> for the install...

And we should also ask a firmware question?

Nope.  I don't think we should bend over backwards for people doing strange
things.  They are on their own.

Re: Allow install from https server w/ self signed cert

[RD Thrush]

On 01/07/17 16:13, Bob Beck wrote:
> 
> On Fri, Jan 06, 2017 at 10:48:37AM -0500, RD Thrush wrote:
>> On 01/06/17 06:28, Stuart Henderson wrote:
>>> Related to this (and particularly thinking about autoinstalls),
>>> would it make sense to allow explicit protocols in the hostname?
>>>
>>> some.host -> https with http fallback
>>> http://some.host/ -> http only
>>> https://some.host/ -> https only, no fallback
>>
>> That would totally work for my install problem.
>>
>> FWIW, instead of running a patched install.sub, "rm /etc/ssl/cert.pem" makes 
>> the install bypass the https attempt.
>>
> 
> Note, if you're upgrading or otherwise have a way to et a cert.pem bundle 
> onto there to *replace*
> the default, you could always drop the signer for your private self-signed 
> server into the cert.pem
> bundle, at which point it would be accepted as trusted.

In an ideal world, I'd have a valid certificate for this local nas server...


> of course if you're just installing you have an interesting chicken and egg 
> problem, unless
> you put it somewhere on an https site that does have a real certificate, drop 
> out of the
> installer and do
> 
> ftp -o /tmp/mysigner.pem https://my.secure.site/mysigner.pem
> cat /tmp/mysigner.pem >> /etc/ssl/cert.pem
> 
> then continue the install, and you're good.

Thanks.  Unfortunately, I've been spoiled by the continually improving snapshot 
install methods and want to preserve typing "a" once for a new -current.


> Almost wonder if it's worth an extra question in the installer to ask
> for an https address to retrieve a certficiate bundle to be appended to 
> cert.pem
> for the install...

That would also solve the self signed cert problem.  Since the install 
/etc/ssl/cert.pem is transient, your method wouldn't trigger any /etc/daily 
alarm about a chang in cert.pem.

I hacked a bit on sthen's suggestion but ran into problems testing the https 
part w/ the OpenBSD servers.  I'm currently unable to do a snapshot autoinstall 
from ftp[35] via the latest bsd.rd.

FWIW, here's my weak attempt at sthen's suggestion:
Index: install.sub
===
RCS file: /cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.942
diff -u -p -u -p -r1.942 install.sub
--- install.sub 4 Jan 2017 13:47:29 -   1.942
+++ install.sub 7 Jan 2017 22:02:52 -
@@ -1502,9 +1502,11 @@ install_files() {
 
 # Get several parameters from the user, and xfer files from the http server.
 install_http() {
+   local _proto=$1
local _file_list _prompt _mirror _url_base _err _idx=/tmp/i/index.txt
local _idx_url _rc
 
+   HTTP_PROTO=$_proto
# N.B.: 'http_proxy' is an environment variable used by ftp(1). DON'T
# change the name or case!
ask "HTTP proxy URL? (e.g. 'http://proxy:8080', or 'none')" \
@@ -1568,8 +1570,9 @@ install_http() {
# Get list of files from the server.
# Assumes index file is "index.txt" for http (or proxy).
# We can't use index.html since the format is server-dependent.
-   # If ftp(1) has tls, fetch index.txt via https. If that fails
-   # tell the user about it and switch to http.
+   # If ftp(1) has tls and doesn't explicitly request http,
+   # fetch index.txt via https. If https fails tell the user about
+   # it and switch to http.
rm -f $_idx
if $FTP_TLS; then
_idx_url=$_url_base/index.txt
@@ -2310,7 +2313,7 @@ feed_random() {
 # selects from that location. Repeat as many times as the user needs to get all
 # desired sets.
 install_sets() {
-   local _cddevs=$(get_cddevs) _d=$CGI_METHOD _im _locs="disk http" _src
+   local _cddevs=$(get_cddevs) _d=$CGI_METHOD _im _locs="disk http https" 
_src
 
echo
 
@@ -2343,7 +2346,9 @@ install_sets() {
;;
[dD]*)  install_disk && INSTALL_METHOD=disk
;;
-   [hH]*)  isin http $_locs && install_http && INSTALL_METHOD=http
+   [hH]*s) isin https $_locs && install_http https && 
INSTALL_METHOD=https
+   ;;
+   [hH]*)  isin http $_locs && install_http http && 
INSTALL_METHOD=http
;;
[nN]*)  isin nfs $_locs && install_nfs && INSTALL_METHOD=nfs
;;

Re: Allow install from https server w/ self signed cert

[Bob Beck]

On Fri, Jan 06, 2017 at 10:48:37AM -0500, RD Thrush wrote:
> On 01/06/17 06:28, Stuart Henderson wrote:
> > Related to this (and particularly thinking about autoinstalls),
> > would it make sense to allow explicit protocols in the hostname?
> > 
> > some.host -> https with http fallback
> > http://some.host/ -> http only
> > https://some.host/ -> https only, no fallback
> 
> That would totally work for my install problem.
> 
> FWIW, instead of running a patched install.sub, "rm /etc/ssl/cert.pem" makes 
> the install bypass the https attempt.
> 

Note, if you're upgrading or otherwise have a way to et a cert.pem bundle onto 
there to *replace*
the default, you could always drop the signer for your private self-signed 
server into the cert.pem
bundle, at which point it would be accepted as trusted. 

of course if you're just installing you have an interesting chicken and egg 
problem, unless
you put it somewhere on an https site that does have a real certificate, drop 
out of the
installer and do

ftp -o /tmp/mysigner.pem https://my.secure.site/mysigner.pem
cat /tmp/mysigner.pem >> /etc/ssl/cert.pem

then continue the install, and you're good. 

Almost wonder if it's worth an extra question in the installer to ask
for an https address to retrieve a certficiate bundle to be appended to cert.pem
for the install...

Re: Allow install from https server w/ self signed cert

[RD Thrush]

On 01/06/17 06:28, Stuart Henderson wrote:
> Related to this (and particularly thinking about autoinstalls),
> would it make sense to allow explicit protocols in the hostname?
> 
> some.host -> https with http fallback
> http://some.host/ -> http only
> https://some.host/ -> https only, no fallback

That would totally work for my install problem.

FWIW, instead of running a patched install.sub, "rm /etc/ssl/cert.pem" makes 
the install bypass the https attempt.

Re: Allow install from https server w/ self signed cert

[viq]

On Fri, Jan 6, 2017 at 12:33 PM, viq  wrote:

> I have another issue. I'm preparing OpenBSD vagrant boxes using
> https://packer.io and use it's built in http server to serve install.conf
> file and siteXY.tgz. The whole setup can be seen at
> https://github.com/viq/packer-templates/ and specifically https://github.
> com/viq/packer-templates/blob/master/openbsd-current/http/
> install_amd64.conf
> The trick is, I have to specify the port that server is listening on,
> which causes install to try to connect to that port using https, and drop
> dead there and then as that fails.
>

And no, there isn't really an option to make it serve https short of
stunnel, and that would still leave an issue of presenting a certificate.

-- 
viq

Re: Allow install from https server w/ self signed cert

[viq]

I have another issue. I'm preparing OpenBSD vagrant boxes using
https://packer.io and use it's built in http server to serve install.conf
file and siteXY.tgz. The whole setup can be seen at
https://github.com/viq/packer-templates/ and specifically
https://github.com/viq/packer-templates/blob/master/openbsd-current/http/install_amd64.conf
The trick is, I have to specify the port that server is listening on, which
causes install to try to connect to that port using https, and drop dead
there and then as that fails.

Re: Allow install from https server w/ self signed cert

[Landry Breuil]

On Fri, Jan 06, 2017 at 11:28:34AM +, Stuart Henderson wrote:
> Related to this (and particularly thinking about autoinstalls),
> would it make sense to allow explicit protocols in the hostname?
> 
> some.host -> https with http fallback
> http://some.host/ -> http only
> https://some.host/ -> https only, no fallback

Definitely in favor of less implicit/magic behaviour..

Re: Allow install from https server w/ self signed cert

[Stuart Henderson]

Related to this (and particularly thinking about autoinstalls),
would it make sense to allow explicit protocols in the hostname?

some.host -> https with http fallback
http://some.host/ -> http only
https://some.host/ -> https only, no fallback

Re: Allow install from https server w/ self signed cert

[Alexander Hall]

On January 5, 2017 11:10:06 PM GMT+01:00, Alexander Hall  
wrote:
>What's the point of installing over https if you don't care about
>validating the cert?

Oh, I read too fast. Please disregard. 

/Alexander 

>
>On January 5, 2017 12:24:11 PM GMT+01:00, RD Thrush
> wrote:
>>Rather than add load to the OpenBSD snapshot servers, for years I
>>download a snapshot to a local netgear nas server.  With the recent
>>https changes, I'm no longer able to install from that server.  I've
>>appended a console log of a failed install attempt.
>>
>>Per src/distrib/miniroot/install.sub v1.940, I added the recommended
>>question to the response file, ie.
>>Unable to connect using https. Use http instead = yes
>>
>>However, the "ftp: SSL write error: certificate verification failed:
>>self signed certificate" message causes the install to abort.
>>
>>Here's the patch I used to account for the self signed certificate:
>>Index: install.sub
>>===
>>RCS file: /cvs/src/distrib/miniroot/install.sub,v
>>retrieving revision 1.942
>>diff -u -p -u -p -r1.942 install.sub
>>--- install.sub   4 Jan 2017 13:47:29 -   1.942
>>+++ install.sub   5 Jan 2017 11:12:32 -
>>@@ -1578,7 +1578,7 @@ install_http() {
>> 
>>  # Consider the https connect failed either if it was refused by
>>  # the server, or it took longer than -w sec (exit code 2).
>>- if ( (($_rc == 1)) && [[ $_err == *'Connection refused'* ]] ) ||
>>+ if ( (($_rc == 1)) && [[ $_err == *'Connection refused'* ]] || 
>>[[
>>$_err == *'self signed'* ]] ) ||
>>  (($_rc == 2)); then
>>  ask_yn "Unable to connect using https. Use http 
>> instead?" ||
>>  return
>>
>>
>> serial console #
 OpenBSD/amd64 BOOT 3.33
>>DiskBIOS#   TypeCylsHeads   SecsFlags   Checksum
>>hd0 0x80label   1023255 63  0x2 0xdce59776
>>hd1 0x81label   1023255 63  0x2 0x2db005d6
>>Region 0: type 1 at 0x0 for 639KB
>>Region 1: type 2 at 0x9fc00 for 1KB
>>Region 2: type 2 at 0xf for 64KB
>>Region 3: type 1 at 0x10 for 2096000KB
>>Region 4: type 2 at 0x7ffe for 128KB
>>Region 5: type 2 at 0xfeffc000 for 16KB
>>Region 6: type 2 at 0xfffc for 256KB
>>Low ram: 639KB  High ram: 2096000KB
>>Total free memory: 2096639KB
>>boot> 
>>booting hd0a:bsd.rd.new: 3396680+1430528+3876632+0+606208
>>[72+431976+281240]=0x9914c8
>>entry point at 0x1001000 [7205c766, 3404, 24448b12, 3550a304]
>>Copyright (c) 1982, 1986, 1989, 1991, 1993
>>  The Regents of the University of California.  All rights reserved.
>>Copyright (c) 1995-2017 OpenBSD. All rights reserved. 
>>https://www.OpenBSD.org
>>
>>OpenBSD 6.0-current (RAMDISK_CD) #103: Wed Jan  4 21:48:20 MST 2017
>>bu...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
>>real mem = 2130575360 (2031MB)
>>avail mem = 2062315520 (1966MB)
>>mainbus0 at root
>>bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf0cd0 (9 entries)
>>bios0: vendor SeaBIOS version
>>"rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org" date
>>04/01/2014
>>bios0: QEMU Standard PC (i440FX + PIIX, 1996)
>>acpi0 at bios0: rev 0
>>acpi0: tables DSDT FACP SSDT APIC HPET
>>acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
>>cpu0 at mainbus0: apid 0 (boot processor)
>>cpu0: Common KVM processor, 3400.46 MHz
>>cpu0:
>>FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,x2APIC,HV,NXE,LONG,LAHF
>>cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
>>64b/line 16-way L2 cache
>>cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries
>direct-mapped
>>cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries
>direct-mapped
>>cpu0: apic clock running at 1000MHz
>>cpu at mainbus0: not configured
>>ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
>>acpiprt0 at acpi0: bus 0 (PCI0)
>>acpicpu at acpi0 not configured
>>"ACPI0006" at acpi0 not configured
>>"PNP0303" at acpi0 not configured
>>"PNP0F13" at acpi0 not configured
>>"PNP0700" at acpi0 not configured
>>"PNP0501" at acpi0 not configured
>>"PNP0A06" at acpi0 not configured
>>"ACPI0007" at acpi0 not configured
>>"ACPI0007" at acpi0 not configured
>>pvbus0 at mainbus0: KVM
>>pci0 at mainbus0 bus 0
>>pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
>>"Intel 82371SB ISA" rev 0x00 at pci0 dev 1 function 0 not configured
>>pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA,
>>channel 0 wired to compatibility, channel 1 wired to compatibility
>>pciide0: channel 0 disabled (no drives)
>>atapiscsi0 at pciide0 channel 1 drive 0
>>scsibus0 at atapiscsi0: 2 targets
>>cd0 at scsibus0 targ 0 lun 0:  ATAPI 5/cdrom
>>removable
>>cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
>>uhci0 at pci0 dev 1 

Re: Allow install from https server w/ self signed cert

[Alexander Hall]

What's the point of installing over https if you don't care about validating 
the cert? 

On January 5, 2017 12:24:11 PM GMT+01:00, RD Thrush  
wrote:
>Rather than add load to the OpenBSD snapshot servers, for years I
>download a snapshot to a local netgear nas server.  With the recent
>https changes, I'm no longer able to install from that server.  I've
>appended a console log of a failed install attempt.
>
>Per src/distrib/miniroot/install.sub v1.940, I added the recommended
>question to the response file, ie.
>Unable to connect using https. Use http instead = yes
>
>However, the "ftp: SSL write error: certificate verification failed:
>self signed certificate" message causes the install to abort.
>
>Here's the patch I used to account for the self signed certificate:
>Index: install.sub
>===
>RCS file: /cvs/src/distrib/miniroot/install.sub,v
>retrieving revision 1.942
>diff -u -p -u -p -r1.942 install.sub
>--- install.sub4 Jan 2017 13:47:29 -   1.942
>+++ install.sub5 Jan 2017 11:12:32 -
>@@ -1578,7 +1578,7 @@ install_http() {
> 
>   # Consider the https connect failed either if it was refused by
>   # the server, or it took longer than -w sec (exit code 2).
>-  if ( (($_rc == 1)) && [[ $_err == *'Connection refused'* ]] ) ||
>+  if ( (($_rc == 1)) && [[ $_err == *'Connection refused'* ]] || 
>[[
>$_err == *'self signed'* ]] ) ||
>   (($_rc == 2)); then
>   ask_yn "Unable to connect using https. Use http 
> instead?" ||
>   return
>
>
> serial console #
>>> OpenBSD/amd64 BOOT 3.33
>DiskBIOS#   TypeCylsHeads   SecsFlags   Checksum
>hd0 0x80label   1023255 63  0x2 0xdce59776
>hd1 0x81label   1023255 63  0x2 0x2db005d6
>Region 0: type 1 at 0x0 for 639KB
>Region 1: type 2 at 0x9fc00 for 1KB
>Region 2: type 2 at 0xf for 64KB
>Region 3: type 1 at 0x10 for 2096000KB
>Region 4: type 2 at 0x7ffe for 128KB
>Region 5: type 2 at 0xfeffc000 for 16KB
>Region 6: type 2 at 0xfffc for 256KB
>Low ram: 639KB  High ram: 2096000KB
>Total free memory: 2096639KB
>boot> 
>booting hd0a:bsd.rd.new: 3396680+1430528+3876632+0+606208
>[72+431976+281240]=0x9914c8
>entry point at 0x1001000 [7205c766, 3404, 24448b12, 3550a304]
>Copyright (c) 1982, 1986, 1989, 1991, 1993
>   The Regents of the University of California.  All rights reserved.
>Copyright (c) 1995-2017 OpenBSD. All rights reserved. 
>https://www.OpenBSD.org
>
>OpenBSD 6.0-current (RAMDISK_CD) #103: Wed Jan  4 21:48:20 MST 2017
>bu...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
>real mem = 2130575360 (2031MB)
>avail mem = 2062315520 (1966MB)
>mainbus0 at root
>bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf0cd0 (9 entries)
>bios0: vendor SeaBIOS version
>"rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org" date
>04/01/2014
>bios0: QEMU Standard PC (i440FX + PIIX, 1996)
>acpi0 at bios0: rev 0
>acpi0: tables DSDT FACP SSDT APIC HPET
>acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
>cpu0 at mainbus0: apid 0 (boot processor)
>cpu0: Common KVM processor, 3400.46 MHz
>cpu0:
>FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,x2APIC,HV,NXE,LONG,LAHF
>cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
>64b/line 16-way L2 cache
>cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
>cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
>cpu0: apic clock running at 1000MHz
>cpu at mainbus0: not configured
>ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
>acpiprt0 at acpi0: bus 0 (PCI0)
>acpicpu at acpi0 not configured
>"ACPI0006" at acpi0 not configured
>"PNP0303" at acpi0 not configured
>"PNP0F13" at acpi0 not configured
>"PNP0700" at acpi0 not configured
>"PNP0501" at acpi0 not configured
>"PNP0A06" at acpi0 not configured
>"ACPI0007" at acpi0 not configured
>"ACPI0007" at acpi0 not configured
>pvbus0 at mainbus0: KVM
>pci0 at mainbus0 bus 0
>pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
>"Intel 82371SB ISA" rev 0x00 at pci0 dev 1 function 0 not configured
>pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA,
>channel 0 wired to compatibility, channel 1 wired to compatibility
>pciide0: channel 0 disabled (no drives)
>atapiscsi0 at pciide0 channel 1 drive 0
>scsibus0 at atapiscsi0: 2 targets
>cd0 at scsibus0 targ 0 lun 0:  ATAPI 5/cdrom
>removable
>cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
>uhci0 at pci0 dev 1 function 2 "Intel 82371SB USB" rev 0x01: apic 0 int
>11
>"Intel 82371AB Power" rev 0x03 at pci0 dev 1 function 3 not configured
>vga1 at pci0 dev 2 function 0 "Cirrus Logic CL-GD5446" rev 0x00
>vga1: aperture needed
>wsdisplay1 at vga1 mux 1: 

Allow install from https server w/ self signed cert

[RD Thrush]

Rather than add load to the OpenBSD snapshot servers, for years I download a 
snapshot to a local netgear nas server.  With the recent https changes, I'm no 
longer able to install from that server.  I've appended a console log of a 
failed install attempt.

Per src/distrib/miniroot/install.sub v1.940, I added the recommended question 
to the response file, ie.
Unable to connect using https. Use http instead = yes

However, the "ftp: SSL write error: certificate verification failed: self 
signed certificate" message causes the install to abort.

Here's the patch I used to account for the self signed certificate:
Index: install.sub
===
RCS file: /cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.942
diff -u -p -u -p -r1.942 install.sub
--- install.sub 4 Jan 2017 13:47:29 -   1.942
+++ install.sub 5 Jan 2017 11:12:32 -
@@ -1578,7 +1578,7 @@ install_http() {
 
# Consider the https connect failed either if it was refused by
# the server, or it took longer than -w sec (exit code 2).
-   if ( (($_rc == 1)) && [[ $_err == *'Connection refused'* ]] ) ||
+   if ( (($_rc == 1)) && [[ $_err == *'Connection refused'* ]] || 
[[ $_err == *'self signed'* ]] ) ||
(($_rc == 2)); then
ask_yn "Unable to connect using https. Use http 
instead?" ||
return


 serial console #
>> OpenBSD/amd64 BOOT 3.33
DiskBIOS#   TypeCylsHeads   SecsFlags   Checksum
hd0 0x80label   1023255 63  0x2 0xdce59776
hd1 0x81label   1023255 63  0x2 0x2db005d6
Region 0: type 1 at 0x0 for 639KB
Region 1: type 2 at 0x9fc00 for 1KB
Region 2: type 2 at 0xf for 64KB
Region 3: type 1 at 0x10 for 2096000KB
Region 4: type 2 at 0x7ffe for 128KB
Region 5: type 2 at 0xfeffc000 for 16KB
Region 6: type 2 at 0xfffc for 256KB
Low ram: 639KB  High ram: 2096000KB
Total free memory: 2096639KB
boot> 
booting hd0a:bsd.rd.new: 3396680+1430528+3876632+0+606208 
[72+431976+281240]=0x9914c8
entry point at 0x1001000 [7205c766, 3404, 24448b12, 3550a304]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2017 OpenBSD. All rights reserved.  https://www.OpenBSD.org

OpenBSD 6.0-current (RAMDISK_CD) #103: Wed Jan  4 21:48:20 MST 2017
bu...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
real mem = 2130575360 (2031MB)
avail mem = 2062315520 (1966MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf0cd0 (9 entries)
bios0: vendor SeaBIOS version 
"rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org" date 04/01/2014
bios0: QEMU Standard PC (i440FX + PIIX, 1996)
acpi0 at bios0: rev 0
acpi0: tables DSDT FACP SSDT APIC HPET
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Common KVM processor, 3400.46 MHz
cpu0: 
FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,x2APIC,HV,NXE,LONG,LAHF
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 
16-way L2 cache
cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: apic clock running at 1000MHz
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu at acpi0 not configured
"ACPI0006" at acpi0 not configured
"PNP0303" at acpi0 not configured
"PNP0F13" at acpi0 not configured
"PNP0700" at acpi0 not configured
"PNP0501" at acpi0 not configured
"PNP0A06" at acpi0 not configured
"ACPI0007" at acpi0 not configured
"ACPI0007" at acpi0 not configured
pvbus0 at mainbus0: KVM
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
"Intel 82371SB ISA" rev 0x00 at pci0 dev 1 function 0 not configured
pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel 0 
wired to compatibility, channel 1 wired to compatibility
pciide0: channel 0 disabled (no drives)
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0:  ATAPI 5/cdrom removable
cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
uhci0 at pci0 dev 1 function 2 "Intel 82371SB USB" rev 0x01: apic 0 int 11
"Intel 82371AB Power" rev 0x03 at pci0 dev 1 function 3 not configured
vga1 at pci0 dev 2 function 0 "Cirrus Logic CL-GD5446" rev 0x00
vga1: aperture needed
wsdisplay1 at vga1 mux 1: console (80x25, vt100 emulation)
virtio0 at pci0 dev 3 function 0 "Qumranet Virtio Memory" rev 0x00
virtio0: no matching child driver; not configured
virtio1 at pci0 dev 10 function 0 "Qumranet Virtio Storage" rev 0x00
vioblk0 at virtio1
scsibus1 at vioblk0: 2 targets
sd0 at