Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

2015-12-08 Thread szs
Not for security.
For privacy.


 Original Message 
Subject: Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/
Local Time: December 8 2015 5:36 pm
UTC Time: December 8 2015 5:36 pm
From: s...@spacehopper.org
To: misc@openbsd.org

On 2015-12-08, szs  wrote:
> So with letsencrypt here, how about making the main site
> default to https? Is this a good idea or is this a great idea?

Don't mistake encryption for security.

Besides, who is going to agree to the Subscriber Agreement and indemnify ISRG?



letsencrypt && https && openbsd.org = https://www.openbsd.org/

2015-12-08 Thread szs
So with letsencrypt here, how about making the main site
default to https? Is this a good idea or is this a great idea?



Re: "bioctl -P" is to change passphrase without wiping the encrypted partition's contents. How do you generate a new keydisk without wipingthesame?

2015-11-20 Thread szs
I think it would make sense to be able to do this. I have a scenario where I 
would like to install OpenBSD on a remote machine with a customized bsd.rd in 
order to automatically set it all up, feeding a password into the stdin of 
bioctl..

Now, bioctl doesn't allow hashed password to be fed into it (as opposed to the 
encrypt command which does for user logins and auto_install)
This leaves me with only one choice, to feed a password into bioctl in order to 
set up the fully encrypted drive, and then change the password with bioctl -P 
afterwards.. Only problem with that is just what was said.. the original 
password could still be used to decrypt the partitions as the keydisk hasn't 
changed.

 Original Message 
Subject: Re: "bioctl -P" is to change passphrase without wiping the encrypted 
partition's contents. How do you generate a new keydisk without wipingthesame?
Local Time: November 20 2015 7:03 pm
UTC Time: November 20 2015 7:03 pm
From: t...@tedunangst.com
To: ti...@openmailbox.org
CC: misc@openbsd.org,owner-m...@openbsd.org

Tinker wrote:
> Aha.
>
> *Is* the keydisk the master key, and hence can't be changed?

The keydisk is the mask for the master key. It can (in theory) be changed like
changing a password. Really, the key disk is just a prehashed password.

>
>
> Very low priority topic:
>
> What about implementing some routine for regenerating the master key,
> even if that would imply reprocessing *all* of the disk's contents?
>
> That could be beneficial in a place where you don't have the space to
> backup 100% of the disk as to start over.

You could, but you'd be really screwed if you crashed halfway. I don't think
the kernel can/should do this, but it is not impossible for a userland utility
to manipulate softraid partitions.



Re: "bioctl -P" is to change passphrase without wiping the encrypted partition's contents. How do you generate a new keydisk without wiping the same?

2015-11-20 Thread szs
I was wondering the exact same thing. Looking forward to finding out.

 Original Message 
Subject: Re: "bioctl -P" is to change passphrase without wiping the encrypted 
partition's contents. How do you generate a new keydisk without wiping the same?
Local Time: November 20 2015 2:13 pm
UTC Time: November 20 2015 2:13 pm
From: ti...@openmailbox.org
To: misc@openbsd.org
CC: owner-m...@openbsd.org

Ah, and maybe equally importantly, what are the security ramifications
of changing password/keydisk vs. wiping and installing from scratch with
a new password/keydisk?


Say that you would change password/keydisk today, and then next week
someone gets a copy of your encrypted disk, and of your previous
password/keydisk.

Would they be able to extract any part of the disk information then, if
not why?


On 2015-11-20 21:58, Tinker wrote:
> "bioctl -P" is to change passphrase without wiping the encrypted
> partition's contents. How do you generate a new keydisk without wiping
> the same?
>
> I.e. I have an encrypted partition /dev/sd0a which is encrypted using
> the keydisk /dev/sd1a . Say /dev/sd1a's contents were compromised. How
> do you generate a new one without needing to wipe /dev/sd0a .
>
> I.e. exactly the same as "-P" but for the keydisk usecase.
>
> (Of course the old keydisk/password is needed at replacement time.)
>
> Thanks,
> Tinker



Re: Mixing auto_install with softraid0 hdd encryption

2015-11-14 Thread szs
That's some great info, a good place for me to start. Thank you!

Kind regards


 Original Message 
Subject: Re: Mixing auto_install with softraid0 hdd encryption
Local Time: November 14 2015 7:24 pm
UTC Time: November 14 2015 7:24 pm
From: nate.whee...@gmail.com
To: s...@protonmail.ch
CC: misc@openbsd.org

On Fri, Nov 13, 2015 at 4:37 PM, szs  wrote:
> I have been playing around with auto_install today, hugely satisfying seeing
> your system install in less than two mins!
>
> I wondering if anyone has any experience mixing this with disk encryption with
> bioctl?
>
> I'm thinking that it may take some hacking about with bsd.rd but I am not sure
> where to start.

I use autoinstall(8) with a CRYPTO disk and yes I compile my own
bsd.rd to do it. You can start by looking at install.sh in
src/distrib/miniroot.

> Does anyone have tips on how I could pass instructions to 'bioctl' and whether
> or not an encrypted hash of the password (such as with 'encrypt -b 8 password'
> could be fed into this and work?

For bioctl you'll probably want to use "-s" to read the passphrase
from stdin. You can't feed it a hash, it will just use that hash as
the actual passphrase.



Mixing auto_install with softraid0 hdd encryption

2015-11-13 Thread szs
I have been playing around with auto_install today, hugely satisfying seeing
your system install in less than two mins!

I wondering if anyone has any experience mixing this with disk encryption with
bioctl?

I'm thinking that it may take some hacking about with bsd.rd but I am not sure
where to start.

Does anyone have tips on how I could pass instructions to 'bioctl' and whether
or not an encrypted hash of the password (such as with 'encrypt -b 8 password'
could be fed into this and work?

Thanks for your time



athn0/AR9287. Having to switch PCI-E slot after every reboot. Weird wireless issues!

2015-11-11 Thread szs
Hi,

Tp-Link TL-WN881ND PCI-E ( Atheros / AR9287 / athn0 )

This adapter works fantastic when it is plugged in to my motherboard, can even 
set it up with
hostap for an access point - great!!

..Until I try to reboot the machine, then it goes crazy and ifconfig says the 
device doesn't exist
etc.. and dmesg is saying not configured!

..But if I place the AR9287 in to a different PCI-E slot and boot up the 
system, everything is
back to normal until I reboot!

This happens in a loop, after every reboot I have to open up the computer case 
and move the
wifi adapter in to another PCI-E slot. The man pages state that the AR9287 
adapter is supported.

Have I stumbled across a bug or am I doing something wrong? Can someone help 
bring reason or
logic to this madness? Here are the outputs:

$ifconfig athn0
athn0: no such interface

$ifconfig athn0 up
ifconfig: SIOCGIFFLAGS: Device not configured.

$cat /etc/hostname.athn0
inet 10.0.0.1 hostap
mediaopt hostap
nwid OpenBSD
wpakey MYPASSWORD

$dmesg | grep athn0
athn0 at pci1 dev 0 function 0 "Atheros AR9287" rev 0x01: apic 6 int 4
athn0: AR9287 rev 2 (2TR2), ROM rev 4, address c4:a4:42:8d:eb:4d

$dmesg | grep Atheros
athn0 at pci1 dev 0 function 0 "Atheros AR9287" rev 0x01: apic 6 int 4
vendor "Atheros", unknown product 0xff1c (class network subclass ethernet, rev 0
x01) at pci1 dev 0 function 0 not configured

-=-=-=-=-=-=
AFTER switching the PCI-E slot and powering up again! Everything just works the 
way it should:
-=-=-=-=-=-=

$ifconfig athn0
athn0: flags=8843 mtu 1500
lladdr c4:a4:42:8d:eb:4d
priority: 4
groups: wlan
media: IEEE802.11 autoselect hostap
status: active
i80211: nwid OpenBSD chan 1 bssid c4:a4:42:8d:eb:4d wpakey 0xf53a736
273ab364c83b836e73273ab364c83b836e73273ab36 wpaprotos wpa1, wpa2
wpaakms psk wpaciphers tkip,ccmp wpagroupcipher tkip
inet 10.0.0.1 netmask 0xff00 broadcast 10.0.0.255

$dmesg | grep athn0
athn0 at pci1 dev 0 function 0 "Atheros AR9287" rev 0x01: apic 6 int 0
athn0: AR9287 rev 2 (2TR2), ROM rev 4, address c4:a4:42:8d:eb:4d

$dmesg | grep Atheros
athn0 at pci1 dev 0 function 0 "Atheros AR9287" rev 0x01: apic 6 int 0