"But if you send an HTTPS request with SSL or TLS enabled, you are practically guaranteed (barring any vulnerabilities in SSL) that no hosts sitting between you and your endpoint were able to modify the data. If they were, it would immediately fail your message digest check, and your browser would give you a big error message."
Originally Posted by allquixotic
this is just wrong because SSE is based on "Trust" and the "Trust" part is the vulnerability because in the past the "Trust" centers allow untrusted people to violate there "Trust" to hijack your "security" (DigiNotar CA certificate abuse) source: http://support.mozilla.org/de/questions/872516
only PGP is save from this kind of attack. '
"This is what secure boot does, but instead of network data, it verifies executable code on disk"
now you get the same problem on the hardware side the Criminal "Microsoft" and the Criminal "Government" get the power of "certificate abuse)
now a example you store your 1 million dollar of Bitcoins on your "server" and you trust "LOL-UEFI-LOL" then the "Good" Government make Bitcoins against the law but only to rape the bitcoins and sell them to earn money for buying weapons to start a "war"
now the government with the name USA go to there company with the name MIcrosoft and do a certificate abuse and now what do you get?
UEFI is only power in the hand of microsoft and govnernment insteaf of power in your hand!
because UEFI is based on "Trust" but first rule in security is: "do not trust"
back to my unbeatable (unbeatable for the real evils like government)solution:
"That sounds pretty secure indeed, but requires toggling a switch on the motherboard each time you want to change any files in the operating system."
this is wrong because this is only the security of the lowest level you build a virtualization with hardware emulation because of this the "Virus" always manipulate the emulated hardware and never the REAL hardware
" Also, this method does not provide any way to verify that all of the binaries present on the system are genuine:"
this is also wrong because the virtualization emulation do have a 1on1 copy of the original files so they can compare it all the time no way to escape this one.
Last edited by Qaridarium; 06-01-2012 at 02:08 AM.
in my point of view its impossible to support linux on UEFI hardware because of the GPL3 and also GPL2 interpretation
Now, obviously, we could provide signed versions of Linux. This poses several problems. Firstly, we'd need a non-GPL bootloader. Grub 2 is released under the GPLv3, which explicitly requires that we provide the signing keys. Grub is under GPLv2 which lacks the explicit requirement for keys, but it could be argued that the requirement for the scripts used to control compilation includes that. It's a grey area, and exploiting it would be a pretty good show of bad faith. Secondly, in the near future the design of the kernel will mean that the kernel itself is part of the bootloader. This means that kernels will also have to be signed. Making it impossible for users or developers to build their own kernels is not practical. Finally, if we self-sign, it's still necessary to get our keys included by ever OEM."
there is a possibility that the kernel and GPLv2 is also incompatible with the UEFI standards.
i hope so! then lawyers can stop this and then Microsoft will get some anti-trust problems to.
security boot and UEFI is just: "The Coming War on General Purpose Computation"
Easy enough: avoid any hardware with a Windows 8 sticker?
This is what I am going to do...
Little example, me buying a netbook:
1. tell the vendor to rip out the hard drive and put a SSD in
2. do not bother to install Windows on it and keep the licence
3. after some research, the third vendor was OK with that
Kanotix is definitely not dead, maybe look at our homepage, we just release a Hellfire (squeeze) update and a Dragonfire (wheezy) preview.
But if EVERYBODY can get a signed bootloader then this system is absolutely pointless. For x86 you just have to find a setup option to disable secure boot - usually secure boot can only work in uefi mode anyway. So when you would force a boot via csm (and bios emulation) how should secure boot be active if thats done via quick boot selection?
If you see secure boot as something positive to your own security that means that could be sure that nobody managed to put in a spy module to save your encryption keys if you encrypt your data like it is possible when you hijack the mbr for this and then execute maybe truecrpt later but store the key.
I don't understand why ms would give away a signed 3rd party efi loader, you can be 100% sure that it will be used for exploits. If you dont need security features you can disable em on your own. It would be interesting to know if there is a uefi spec to update the included public keys. Basically it should not be that hard to do when you have got access to the uefi, you can extract, change (there are several tools to modifiy uefi, just for another purpose currently) and flash your own keys.
Even if the key area would be write protected after first write you could still replace the eeprom chip, which is a piece of cake on a desktop system, well could be tricky on a laptop. When YOU are able to control it, then you can gain a little bit more security, if you cant it would be just like without.
In the comments section, someone asked about TPM, and the response was that SecureBoot is designed not to require one.
Originally Posted by linux5850
i know your releases ok bad style it was more a question will you support secure-boot in the future and will you pay 100 dollar to microsoft ?
Originally Posted by Kano
No i wont because if somebody does not find the option to disable secure boot he is most likely not able to use linux as well...
I think there are better reasons to use Kanotix. But you should not mix up standard uefi booting with secure boot. uefi boot is really cool when done correctly - especially with a kernel with efi stub. It is a bit weird that you can use "rdev" now for that purpose which was already dropped from utils-linux because nobody used it...