Bug#857888: Debian 9 RC ISO installers lacks apt-transport-https package
Package: debian-9-rcX.iso Version: debian-9-rc1/2/+? The Debian 9 RC installers now allow for HTTPS APT repos, but they will not work because apt-transport-https is missing (and thus cannot parse HTTPS sources during installation). I suggest adding apt-transport-https to the new RC installer images so that HTTPS sources can work during the public release of Debian 9. Tested Debian 9 RC 1, 2, and dailies.
Bug#814798: debian-installer: enable encrypting /boot using GRUB cryptomount
I would also like to express a vote for true full disk encryption within the Debian installer. The current form of FDE leaves the /boot partition unencrypted. This can be fixed and has been tested on Debian Stretch to work. The process should be as so: * Create RAID / DM / MD devices (if necessary to combine multiple physical devices) * Create one encrypted base volume, and utilize LVM2 for each desired partition on top of the encrypted volume (eg. /boot, /home, /, swap, etc). The installer will run fine in this configuration, but the final grub install will fail. This is because of the following needs to be added: /etc/default/grub GRUB_ENABLE_CRYPTODISK=y Upon that, grub-install / update-grub should work fine and become bootable. Since the encrypted volume is the first volume to be unlocked upon reboot, you will be asked for your crypto disk unlock key twice, and I am not sure of a secure way around that. Using an external key added to the LUKS slot to automatically boot, as some have suggested, allows decryption of all partitions if that key is lost or stolen. The device needs to be unlocked twice since first time is for /boot to load the kernel, and the second time is to load the standard partitions previously defined. The debian-installer needs to enable support for the Grub cryptodisk option in order to make any progress in a true FDE configuration where the /boot partition is protected. Currently, Debian's "FDE" is slightly more vulnerable to the "Evil Maid" attacks if the attacker modifies the kernel boot image, which is unencrypted. They may even do so in a way that waits until all partitions are unlocked before planting a backdoor post-boot in the user's decrypted environment. Eg. stealing local keys from /home. As such, at the present time, the Debian "Full Disk Encryption" should actually be called "Partial Disk Encryption".
Bug#858009: Debian "Full Disk Encryption" is a misnomer, /boot not encrypted, Evil Maid attacks, enable grub cryptodisk, improve guided encrypted partitioning
Package: debian-installer Version: stretch-rc2 The Debian Stretch RC2 installer and previous versions do not allow Full Disk Encryption since /boot is more vulnerable to Evil Maid attacks due to it being unencrypted. Securing /boot makes Evil Maid attacks slightly more difficult, raising the cost / time for an adversary with physical access. I suggest looking at prior bugs from over a year ago suggesting how to start fixing this by enabling the cryptodisk option for grub, then modifying the debian-installer flows to automatically partition using a base encrypted volume for which all other partitions / LVM2 groups sit atop of, including /boot. This would hopefully replace the current and slightly more insecure "Guided - Use Entire Disk and Set Up Encrypted LVM..." option. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814798 Tested Debian Stretch RC2 and prior versions.
Bug#865649: cups HTTPS issues -- Lack of SHA-2 certificate, weak TLSv1.0 crypto
Package: cups Version: 2.2.1-8 * SHA-1 is officially deprecated for HTTPS certificates, but is still used for cups certificate generation. * TLSv1.0 is enabled for cups, but TLSv1.0 with CBC / SHA-1 is potentially vulnerable to BEAST attacks. I suggest two resolutions to correct this, even though it is understood that default certificates are self-signed anyway. * Generate SHA-2 signed certificates by default. This will lessenthe additional browser warnings. * Enable only TLSv1.2 for the cups HTTPS interface and disable CBC and SHA-1 crypto. TLSv1.0 has numerous known, potential security issues with CBC / SHA-1 suites. All current web clients support TLSv1.2 and so disabling TSLv1.0 should have no negative effect for local Debian users and is likely to also have virtually no impact for remote cups users as well accessing the cups interface remotely. Verified on Debian GNU/Linux 9
Bug#865649: cups HTTPS issues -- Lack of SHA-2 certificate, weak TLSv1.0 crypto)
Was TLSv.1.0 already disabled back in July 2015 and this is a regression or is it time now to disable it permanently and completely in the default config? See below a prior changelog. cups (2.1~b1-1) * New 2.1~b1 release disable TLS/1.0 support. -- Didier Raboud Thu, 09 Jul 2015
