Moxie Marlinspike

> mixing of HTTP/HTTPS content

This is ALWAYS a bad idea. A few points:

- The only purpose of HTTPS and encrypting communications in general is to prevent MITM attacks.

- If your server is even willing to serve unencrypted requests it exposes your users to sslstrip attacks (http://www.thoughtcrime.org/software/sslstrip/). In reality you still should serve HTTP requests but only to force a redirect to HTTPS. In addition you should use the 'Strict-Transport-Security' header. It's the ONLY way to prevent future sslstrip attacks.

- Even worse, if you don't set the 'secure' flag on session cookies at a minimum (thus forcing logged in users to HTTPS only) you expose your users to session hijacking without even putting up a fight.

- If you aren't going to bother with forcing HTTPS all the time then there's not much point as you've opened up your users to simple sslstrip attacks followed by session hijacking or even worse, script injection or redirects.

One fundamental concept many people seem to forget as well is that the dangers of not encrypting communications extends beyond snooping. Attackers can actually modify the data stream to inject and/or replace content or even redirect users entirely.

Also, even if you only serve secure content yourself but you include insecure content on your page it exposes security vulnerabilities. Let's say you include unencrypted images on your site and you have users that are using a client with an image rendering engine vulnerability that…

The proposal for forward secrecy in the spec (https://darkmail.info/downloads/dark-internet-mail-environment-december-2014.pdf) is not great and does not reflect the current state of the art:

> PFS for message objects, as the description above suggests, is far more difficult, and contrary to the nature of email.

It recommends just rotating public keys every few days with a paranoid mode. A much better solution is to implement the Axolotl Ratchet pioneered by Open Whisper Systems for TechSecure:

https://www.whispersystems.org/blog/advanced-ratcheting/

https://github.com/trevp/axolotl/wiki

With Axolotl Ratchet, you get:

* forward secrecy - disclosure of private keys doesn't let an attacker in the future go back and read encrypted communication

* future secrecy - disclosure of ephemeral private keys doesn't disclose (much) future content

I also get the feeling from a glance reading the spec that way too much trust is being placed on service providers. That there is even such a category as "trustful" where the server has access to your private keys is a huge red flag and that was exactly the problem with lavabit: http://www.thoughtcrime.org/blog/lavabit-critique/

Vuln reward programs that payout at this level are broken.

1) They don't achieve their objective of securing a product. Moxie eloquently captured why here: http://thoughtcrime.org/blog/telegram-crypto-challenge/

2) At this level of payout, they are inefficient and unsustainable. There were less expensive ways to discover implementation flaws, and certainly more direct ways to discover design flaws. Was the lesson they just learned really worth $100 grand from some random dude on the Internet? Seems to me you could find more problems per dollar by directly engaging with some of the top class security consultancies out there.

So to summarize, telegram's reward was an extremely inefficient stunt that did not achieve it's likely real objective. I imagine the team is licking it's wounds right now and regretting their approach. We'll be able to tell by whether or not they continue their offer under the same rules and same budget.

I expect this to continue for another couple of rounds because random security people on the Internet will be smelling blood right now.

> DNSSEC does one task extremely well – but it does only this one task:

DNSSEC ensures that the information the operator of a
domain[..] put into DNS is the exact same information
that a user gets out of DNS when they request info for
a domain.

Even this is not true. DNSSEC is an abysmal protocol. To quote from [1]:

DNSSEC suggests a complicated mechanism to essentially re-create many of the
same problems with X509 and CAs in DNS itself, by providing a chain of trust
to untrustworthy entities. Its intended goal is to secure DNS and thereby
assure clients that when they ask for apple.com, they are actually visiting
apple.com. This proposal does not protect against MITM attacks [2]. It suffers
from extreme and unnecessary complexity, a systemic fault that's antithetical
to secure systems. See also this list of resources on why DNSSEC is considered
harmful [3].

[1] http://okturtles.com/#oktvs

[2] http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity/

[3] http://ianix.com/pub/dnssec-outages.html

http://www.thoughtcrime.org/blog/lavabit-critique/

The whole thing is worth a read but here's the gist

"Unlike the design of most secure servers, which are ciphertext in and ciphertext out, this is the inverse: plaintext in and plaintext out. The server stores your password for authentication, uses that same password for an encryption key, and promises not to look at either the incoming plaintext, the password itself, or the outgoing plaintext.

The ciphertext, key, and password are all stored on the server using a mechanism that is solely within the server’s control and which the client has no ability to verify. There is no way to ever prove or disprove whether any encryption was ever happening at all, and whether it was or not makes little difference... The operator can at any time stop averting their eyes, an attacker who compromises the server can log the password a user transmits, and an attacker who can intercept communication to the server can obtain the password as well as the plaintext email."

I don't see why this is modded down. /menu.gpxe seems to be the entry point. Looking at that page shows us that /menu.cfg is the next hop, which points directly to kernel inages, such as /3018/boot.gpxe. I don't see anything that would allow you to authenticate netboot.me in these files, and given the recent null-prefix flaws in SSL (linked from http://www.thoughtcrime.org/software/sslsniff/), I wouldn't feel confident that the netboot code has got SSL implemented correctly, if it's even used for netboot.me. I would consider MITM attacks on netboot.me to be worthy of investigation before using netboot.me, especially if they add WiFi support.

The gPXE security page (http://www.etherboot.org/wiki/safebootmode) seems to indicate that security for gPXE in general is a work in progress.