* Posts by martin__r

6 posts • joined 29 Nov 2017

Let's see what the sweet, kind, new Microsoft that everyone loves is up to. Ah yes, forcing more Office home users into annual subscriptions


Shameless RIP OFF!!! 32x price hike

The useful software lifetime of an office suite is 10 years (bare minimum).

$15 for 10 years = $ 15

$49 * 10 for 10 years = $ 490

That is a whooping 32.6x price hike, not just tenfold. And who says that the $49 subscription fee is cast in stone for the next 10 years, and Microsoft isn't going to hike it further ???

You may want to consider moving to LibreOffice ...

Forgotten that Chinese spy chip story? We haven't – it's still wrong, Super Micro tells SEC


It would be surprising if the Chinese had *NOT* done this.

It should not be surprising that they do not want to fall behind NSA, which got their own backdoor (within IntelME) directly into the CPUs and Chipsets.

TLS developers should ditch 'pseudo constant time' crypto processing


Lucky 13 is an *INSIDER* attack, not an attack against true properties of TLS

The security properties of TLS are described in rfc5246 Appendix F.

Lucky13 is not an attack against TLS itself, but an attack against a rogue endpoint, which is aiding the attacker to perform an insider chosen plaintext attack against TLS. This is only possible with negligently design-flawed endpoints, such as Web Browsers, or stuff that is needlessly and negligently multiplexing data from different sources (including from the attacker) over a single TLS-encrypted channel, such as "SSL-VPNs".

There is an explicit warning in rfc5246:

Any protocol designed for use over TLS must be carefully designed to deal with all possible attacks against it. As a practical matter, this means that the protocol designer must be aware of what security properties TLS does and does not provide and cannot safely rely on the latter.

but it seems web browser suppliers can not read.

Rather than respecting TLS clearly stated design limits (network-based attacker), they want TLS to protect against whatever stupid behaviour they come up with.

If Brussels wants Android forks, phone makers aren't helping


Android bootloader unlocking

Rather than handing out bootloader unlock codes (which you can use to root/hack _someone_elses_ phone, Huawai could have done like Samsung, which provides an "OEM unlock" in the Developer options of the Android settings.

While "OEM unlock" is disabled Samsung phones will not allow custom bootloader nor custom recovery images to run.

this kind of soft-bricks every rooted Samsung phone if you accidentally disable OEM unlock in the developer options and then reboot the phone.

After poweron, the phone reports "Custom binary blocked by FRP Lock" and switches itself off.

This seems to also prevent loading the battery (which is silly!)

The message talks about "FRP lock" but actually this is about OEM unlock of the bootloader"

To fix such a soft-bricked Samsung phone, you have to start the phone into firmware download mode (which still works!), and then use ODIN to flash back an original Samsung Bootloader. Flashing only the bootloader will be sufficient -- and by flashing only the bootloader, you will not loose any data! With the genuine Samsung Bootloader, the phone will boot, allow you to go the settings & developer options, and to re-enable "OEM unlock", and after that you can root your phone again (a process that modifies the phone's bootloader).

How to flash only the bootloader is less obvious, You can extract the bootloader from an official Samsung firmware image for the phone, and then repackage only the boot.img into a tar file with the appropriate tar comamnd line options, and then append a textual MD5 checksum to the file, to make it a boot.tar.md5 which Odin will flash.

It's time for TLS 1.0 and 1.1 to die (die, die)


Anyone still running Windows XP probably knows why, and the reason is *NOT* MSIE 8 (or 7 or 6).

Redmond was never good at browsers and MSIE / Edge are at best "graphical download tools for a real web browser".

Windows XPsp3 is still the the version of Microsoft Windows with the least amount of serious security holes (no kidding!), it is still under active maintenance (just needs a registry key set to keep downloading patches), and earlier this year, Microsoft actually did ship an implmenetation of TLSv1.2 update for it: KB4019276



IBM figures out it takes longer than a week to re-wire software


Stop whining about TLSv1.0 and TLSv1.1, both are secure enough

The advantage of TLSv1.2 over TLSv1.1 & TLSv1.0 is small, and irrelevant in practice. Both, TLSv1.0 and TLSv1.1 have all security properties guaranteed for TLSv1.2 rfc5246 Appendix F.


While allowing TLSv1.2 is trivial for servers, proposing TLSv1.2 for clients still results in interop problems. Send a ClientHello with ClientHello.client_version = TLSv1.2 and no TLS extensions to a Microsoft Schannel 2008R2 or 2012R2, and it'll choke and abort the handshake. Send the very same wrapped as SSLv2Hello, and it'll succeed the TLS handshake (albeit selecting TLSv1.1).

Similarily, if you have (accidentally) enabled SSLv2 in addtion to TLSv1.2 in MSIE 11, and try to connect to a server that supports and negotiates TLSv1.2 in response, Microsoft SChannel (MSIE) chokes and aborts.

btw. just look at the huge amount of Microsoft Software that requires non-trivial end-user opt-in to enable TLSv1.2:

Stuff based on WinHTTP, such as WebDAV in Microsoft Office needs a hotfix *PLUS* adding registry keys:


Situation with Microsoft .NET is similar:



Stop whining about TLSv1.0. All attacks are either purely theoretical, or desperately require all three web browser design flaws (1) unlimited automatic silent downgrade dance, (2) execution of arbitrary attacker-supplied active content and (3) universal cross-site-request-forgery for silly demos.

Biting the hand that feeds IT © 1998–2019