Environment Variables Considered Harmful for Your Secrets - <AUTHOR> http://movingfast.io/articles/environment-variables-considered-harmful/ <comment><USER2> This article is misguided. Environment variables can be more secure than files. Furthermore, in the presented case there's no improvement in security by switching to a file.

To address my second claim first: file permissions work at the user or group level. ACLs / MAC likewise. SELinux can be configured to assist in this case but it's not as trivial as it appears at first glance, it would be easier to use environment variables.

In the example case of spawning imagemagik, it's running as the same user and therefore has the same level of access to the properties file. That is, it can access the secrets without negotiating any authorisation to do so.

Depending on how imagemagik is launched and how the parent process handles the config file, it's possible that imagemagik could inherit a file handle, already open to the file.

Now to address my first claim, if the parent process is following best practice then it will sanitise the environment before exec'ing imagemagik, that should mean launching the imagemagik process with only the environment it needs.

To give a concrete example, the postfix mail transfer agent is extraordinarily high quality software, its spawn process owns the responsibility of launching external processes, potentially sysadmin supplied / external to postfix. This case would be very comparable to the web app invoking imagemagik.

We can see that it explicitly handles this case as I've suggested is best practice: [https://github.com/vdukhovni/postfix/blob/master/postfix/src...](https://github.com/vdukhovni/postfix/blob/master/postfix/src/spawn/spawn.c)

EDIT: accidentally posted before finishing.

If the parent sanitised the child's environment, then the only way for the child to access the data would be to read the parents memory. In practice this is quite easy - try the "ps auxe" command for a sample, however this access can much more easily be controlled by SELinux policy than can file access.

Any obfuscation technique applicable to a config file can similarly be applied to an environment variable.

<comment><USER3> Thanks. I'm mainly looking at this from the point of how your secrets could be accidentally exposed.

I applaud to postfix for sanitising the ENV, and it's very good practice to do so. But are all the frameworks doing it correctly? Maybe some code is then also just spawning new processes without sanitising? You could argue that's a bug then (which I completely agree), but not all projects are run like postfix...

<comment><USER4> The basic system call, execve, requires that you specify the environment explicitly. The whole idea of an inherited environment is a construct of shells and historic libc functions, and the libc functions that do not have an explicit environment should be deprecated. The man page examples show constructing the environment from scratch, which is best practise: you should never refer to the whole environment, just access individual items from it, ie never reference environ, just getenv etc.

</comment></comment></comment><comment><USER5> My company has an internal bit of infrastructure that I think is a somewhat novel approach that allows us to never have any secrets stored unencrypted on disk. There's a server (a set of servers, actually, for redundancy) called the secret server, and its only job is to run a daemon that owns all the secrets. When an app on another server is started up, it must be done from a shell (we use cap) which has an SSH agent forwarded to it. In order for the app to get its database passwords and various other secrets, it makes a request to the secret server (over a TLS-encrypted socket), which checks your SSH identity against an ACL (different identities can have access to different secrets) and does a signing challenge to verify the identity, and if all passes muster, it hands the secrets back. The app process keeps the secrets in memory and your cap shell disconnects, leaving the app unable to fetch any more secrets on your behalf.

The other kink is that the secret server itself reads the secrets from a symmetrically-encrypted file and when it boots, it doesn't actually know how to decrypt it. There's a master key for this that's stored GPG encrypted so that a small number of people can retrieve it and use a client tool that sends the secret server an "unlock" command containing the master key. So any time a secret server reboots, someone with access needs to _gpg --decrypt mastersecret | secret_server_unlock_command someserver_

There are some obvious drawbacks to this whole system (constraining pushes to require an SSH agent connection is a biggie and wouldn't fly some places, and agent forwarding is not without its security implications) and some obvious problems it doesn't solve (secrets are obviously still in RAM), but on the whole it works very well for distributing secrets to a large number of apps, and we have written tools that have basically completely eliminated any individual's need to ever actually lay eyes on a secret (e.g. if you want to run any tool in the mysql family, there's a tool that fetches the secret for you and spawns the tool you want with MYSQL_PWD temporarily set in the env, so you need not copy/paste it or be tempted to stick it in a .my.cnf).

<comment><USER6> The system sounds very well thought-out, though probably not applicable at my $work location.

> When an app on another server is started up, it must be done from a shell

That's a no-go for many setups. It doesn't integrate well with how Linux distros usually start services (systemd, upstart, sysv init, ...), and means you have to have another way to manage dependencies between your services.

> When an app on another server is started up, it must be done from a shell > (we use cap) which has an SSH agent forwarded to it. In order for the app to > get its database passwords and various other secrets, it makes a request to > the secret server (over a TLS-encrypted socket), which checks your SSH > identity against an ACL

At this point you could have used ssh right away, no? Any reason you used TLS + checking SSH agent instead?

<comment><USER7>
      > That's a no-go for many setups. It doesn't integrate well
      > with how Linux distros usually start services (systemd,
      > upstart, sysv init, ...)

Change the daemon config file to use a small wrapper script, which initializes the SSH environment and then execs the target binary. Assuming a reasonable setup, this should be trivial.

      > At this point you could have used ssh right away, no?
      > Any reason you used TLS + checking SSH agent instead?

It sounds like they take an SSH identity certificate from the agent, send it via TLS, and then the remote process verifies it. This would have fewer potential security issues than trying to lock down a user's SSH login shell.

<comment><USER6> > Change the daemon config file to use a small wrapper script, which > initializes the SSH environment and then execs the target binary. Assuming a > reasonable setup, this should be trivial.

Well, the point is that the ssh needs to have forwarded agent from somewhere else. If the host on which the service is run can initiate it, the whole security aspect is gone.

> This would have fewer potential security issues than trying to lock down a > user's SSH login shell.

Locking down a login shell (usually be not running a shell in the first place) is a solved problem, and for example gitolite uses it has the base of its architecture. Yes, you have to be careful, but you must also be careful when manually validating certificates.

</comment></comment></comment></comment><comment><USER8> There's a not-widely-publicized feature of Linux that allows programs to store secrets directly in the kernel: [https://www.kernel.org/doc/Documentation/security/keys.txt](https://www.kernel.org/doc/Documentation/security/keys.txt) That has some advantages, including the guarantee that it can't be swapped to disk. Kerberos can use it for secret storage, I haven't seen it used elsewhere though.

It looks like process-private storage is one of its features.

<comment><USER9> I haven't looked to hard at the docs yet, but this seems kind of awesome. Is it something that you have to build your own kernel for, or is it configurable in a prebuilt kernel?

<comment><USER10> Stock ubuntu here has a /proc/keys file, so I think it's generally available.

</comment></comment></comment><comment><USER11> Classic UNIX behavior was that environment variables were public (any user could see them with the right flags to "ps") so it was well-known not to put anything secret there.

Most (all?) of the current brand of UNIX variants have locked this down quite a while ago, which is a good thing. There are still a few old boxes kicking around though so if you're writing code that is meant to be widely deployed please don't put stuff there. For example: [https://github.com/keithw/mosh/issues/156](https://github.com/keithw/mosh/issues/156)

Even if you are sure that your code will only be running on modern machines I think this article gives good advise. Unless you purge the secret environment variables when you launch they'll get sent to all of your subprocesses and it's quite possible that one of them won't consider their environment secret.

<comment><USER12> This is the best argument for not doing this imo.

"Classic UNIX behavior was that environment variables were public (any user could see them with the right flags to "ps") so it was well-known not to put anything secret there."

The same logic applies to Windows environments and modern *nix too...

Storing private data in a public location is obviously a bad idea.

<comment><USER13> Ok, but that's classical behaviour. Modern *nix behaviour is treating the environment as private data.

I don't get the reason for all that disagreement. Both methos have clear practival advantages and problems, and both are nearly as secure as the other. Use whatever fits better your problem.

</comment></comment></comment><comment><USER14> I've always been uncomfortable with the "store config in the environment" part of the 12 factor app thing, since it does imply storing things like database passwords and such, and the argument is that those _shouldn 't_ be in files. But, filesystem permissions are reasonably flexible and are easy to reason about (unlike the potential visibility of ENV).

I also don't really buy the arguments for ENV storage of even non-sensitive data. There's just not really any good reason to do so; your config has to be put in place by _some_ tool, even if it is in ENV; why not make your tool produce a file, with reasonable permissions in a well-defined default location? The 12 Factor App article seems to believe that config files live in your source tree, and are thus easily accidentally checked into revision control. That's not where my config files live. My config files live in /etc; or, if I want it to isolate a service to a user, I make a /home/user/etc directory.

One could say, "Don't store passwords in the revision control system alongside your source." And that would be reasonable. But, there's no reason to throw the baby out with the bath water.

<comment><USER15> > filesystem permissions are reasonably flexible

Env makes things really flexible.For instance,you can call a program with env variables directly thus overriding the default ones,which simplify configuring applications. You dont have to have a test set-up,a production-setup or a staging set-up,just start a server or an app with different env variables in the command line.

You don't want your config or keys to depend on an OS,or a language. Finally Env variables can be restricted to a set of users,so third party process started with a different one cant access them.

I believe env variables are better than other solutions.

<comment><USER16> >just start a server or an app with different env variables in the command line.

Just reference a different config file on the command line.

>You don't want your config or keys to depend on an OS,or a language.

A path to a config file isn't an OS or language. The ini format is pretty widely supported.

>Finally Env variables can be restricted to a set of users,so third party process started with a different one cant access them.

This is exactly what filesystem permissions do for files already.

<comment><USER17>
        BEGIN {
            $API = new Backend($ENV{credentials});
            delete $ENV{credentials};
        };

Filesystem permissions do _not_ make it possible for a program to internally partition access to those credentials unless you (a) start it as root, or (b) delete the credentials file after reading it.

<comment><USER18> A user process can start subprocesses under different users, without access permissions to the files owned by parent. The most obvious way to do so is to use sudo.

<comment><USER17> Using a setuid helper (even if it's called sudo) is still starting a program as root.

<comment><USER18> Not necessarily; sudo on Fedora has CAP_SETUID instead of the setuid bit, so it doesn't actually run as root.

[http://fedoraproject.org/wiki/Features/RemoveSETUID](http://fedoraproject.org/wiki/Features/RemoveSETUID)

<comment><USER19> But CAP_SETUID, unless I'm confusing it with something else, can be used to set the UID to 0 and thereby gain all the same privileges as if the program had been started as root, can't it? Presumably it has some advantage that I'm not getting – does it have to be combined with e.g. SELinux to be useful?

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER20> Installing secrets on disk exposes them to potential leakage through backups. This is a major issue, since much less attention is typically paid to access management for backups than to production servers. Therefore I support the approach of providing secrets through the environment.

Once an application has been written to get its secrets from the environment, there is a question of how the secrets are obtained. They can be sourced from a file in an init script, but today we are seeing a lot of momentum towards containerized architecture, and the use of service discovery and configuration systems like etcd, zookeeper and consul.

However, secrets require much more attention to security concerns than the data that these tools are designed to handle. Least privilege, separation of duties, encryption, and comprehensive audit are all necessary when dealing with secrets material. To this end, we have written a dedicated product which provides management and access for secrets and other infrastructure resources (e.g. SSH, LDAP, HTTP web services). The deployment model is similar to the HA systems provided by etcd, consul, SaltStack, etc. It's called Conjur (conjur.net).

<comment><USER21> Looks interesting. However, isn't the conjur API key stored in .netrc just another secret that can be easily leaked?

On the distribution as a virtual appliance: is it a black box? How do I back it up? How do I upgrade it? How do I check the integrity of the secrets database?

<comment><USER20> Regarding the API key, from an operational perspective it's an improvement. The reason is it creates a separation of duties between management of the API key (responsibility of opsec), and the application credentials (responsibility of the broader ops team and in some cases the developers themselves). There is no way for the application credentials to be accidentally leaked or mis- deployed, because the policies created by opsec are always enforced.

In addition, the security team can make decisions about the management of the API key, such as:

* It can be kept off physical media (e.g.in /dev/shm)

* The process(es) by which the API keys are created and placed on the machines can be carefully managed

* A dedicated reaper/deprovisioner process can be used to retire (de-authorize) API keys once they go out of service.

Regarding the virtual appliance:

* Is it a black box? Essentially yes, although there are specific maintenance scripts on the machine (e.g. backup / restore) that you may occasionally run. For normal operation, only ports 443 and 636 (LDAPS) are open.

* How do I back it up? A standby master and read-only followers can be used to keep live copies of the database. A backup script can be used to capture full GPG-encrypted backups. A restore script will restore a backup onto a new appliance.

* How do I upgrade it? You create a standby master and followers of the new upgraded version of the appliance, and connect them to your current master. Once the standby master and followers are current with the data stream, they are promoted via DNS and serve the subsequent requests.

* How do I check the integrity of the secrets database? We have written an open-source Ruby interface to OpenSSL called Slosilo ([https://github.com/conjurinc/slosilo](https://github.com/conjurinc/slosilo)) and subjected this library to a professional crypto audit. On the advice of the auditors, Slosilo encryption employs message authentication (cipher mode AES-256-GCM) which ensures the integrity of the secrets. Nevertheless, the Conjur appliances must obviously be afforded the highest level of protection. Unlike a multi-master system, Conjur's read-only "followers" contain only read-only copies of the secrets. So compromise of a follower cannot be used to modify secrets or authorization policies, or to confuse a master election scheme.

<comment><USER21> Thank you for the reply.

</comment></comment></comment></comment><comment><USER22> Fundamentally, any secrets you store will have some mode of access - there's a downside to each and every way of distributing them.

If you're shelling out to commands you think might snarf credentials, the environment is easy for them to pick it out of, but if they're running as the same user then they could probably read the secrets from the config file. If they aren't running as the same user, you need a way of passing in the secrets - and we tend to come back to environment variables..

The good practice here is just to reset the environment when calling shell commands, as he notes. It's not hard to do.

<comment><USER23> You could use a kernel service that checksums the calling DLL or even all code loaded in the calling process and compares that against a list of trusted callers before doling out the secret.

Disadvantage, of course, is that you will have to update the list of trusted callers whenever they change. Mac OS X automates that by automatically trusting binaries signed with the same key (trades some security for convenience)

Another disadvantage is that this doesn't work well with scripts (the kernel service would have to know how to find the running scripts in order to checksum them, for every possible scripting language on the system). Also, any form of extension support in a trusted application is problematic.

<comment><USER24> Wow, this is the only thing I've seen in this thread which doesn't just add another layer of turtles to the problem. With your suggestion, even if an attacker could gain access to the box, they wouldn't be able to get at the secrets. Is there any prior art/blog posts/software for this approach you could point me at?

<comment><USER23> For the Mac OS X technology, [https://developer.apple.com/library/mac/documentation/Securi...](https://developer.apple.com/library/mac/documentation/Security/Conceptual/CodeSigningGuide/AboutCS/AboutCS.html) is a good starting point.

I don't know of full open source equivalents. Parts of Apple's code are open source, though, for example [http://opensource.apple.com/source/security_systemkeychain/s...](http://opensource.apple.com/source/security_systemkeychain/security_systemkeychain-55202/src/) (may not even compile; not all Apple's open source releases do)

</comment></comment></comment></comment><comment><USER25> Ultimately, secrets need to live somewhere and need to be accessed as plain text. Just make sure that the access as small window is as possible, and try to obliterate it after use, if possible.

If one absolutely needs to centralize secrets (TLS/SSL private keys, entropy sources, etc.) (at risk of SPOF or some HA setup), use some PSK style setup that delivers them directly, out-of-band (via separate NICs) or prioritized ahead of regular traffic. Keep it simple. Otherwise, prefer something like zookeeper with encrypted secrets (again PSK keying per box). Try to not deploy the same secret on every box, if possible. Also, try to avoid magic secrets if you can too (remove all local password hashes, use only auth keys).

If you're uncomfortable with plaintext secrets, encrypt them (as end-to-end as possible) and require an out-of-band decryption key at the last possible moment.

It's like having a secure document viewing system... ultimately, someone will need to browse just enough of the plaintext version, or it's not a document viewing system.

</comment><comment><USER26> Isn't this what TPM was designed to avoid ?

Neither files nor env variables.

Most chipsets have a rather unused TPM function, and it should be possible to have developers and processes hook into that.

Perhaps using tmptool ? On master process startup ask user for passphrase, and use that to query the TPM stored values ?

[http://manpages.courier- mta.org/htmlman1/tpmtool.1.html](http://manpages.courier- mta.org/htmlman1/tpmtool.1.html)

<comment><USER3> I have to admit that I don't know a thing about TPM. Like is it also available in virtual environments like AWS is providing? How could this be automated? You don't want to enter a passphrase every time a server (re)boots. Would love to hear if anybody successfully used that.

<comment><USER26>
      Cloud servers
      </comment></comment></comment><comment></comment><comment>=

Xen supports virtual TPM.

I'm no Amazon EC2 expert, but a quick google exposed a few keen souls who tried to use vTPM and failed. This would suggest that Amazon does not yet support vTPM.

      Re-entering passphrases
      </comment><comment></comment><comment></comment><comment></comment><comment>

Well, unless the machine is permissioned by default you will need to give a fresh instance new authorization. Permissioning by default is the same security problem you're trying to avoid though... just shifted. Your overall goal is to have the credentials inaccessible to sniffing, right ?

I guess you could set up some form of ssh-agent handshake to make the process less manual.

<comment><USER3> sniffing isn't the main issue I'm trying to avoid, it's accidental exposure. I.e. minimising the risk that during normal operations the secrets get exposed somehow.

<comment><USER26> Okay... sniffed accidentally then ( putting them in the wrong directory, not using fs permissions properly etc )

I would say that you should consider malicious sniffing too

</comment></comment></comment><comment><USER27> Please don't use environment variables to store secrets. There are to many angles - as stated by others - where this data may leak into files or processes.

I would propose to use just one folder like /secret and put your config files in there. Exclude this folder from backup on all relevant hosts.

Then spend your time on security of your hosts, applications (OWASP) and monitoring / alerting. Something that you have to do anyway.

</comment><comment><USER28> Assuming you arn't trying to go for top security, and just want a way to keep things safe from leaking due to errors and the such

why not just make use of the OS's secrets store? for example, like how [https://pypi.python.org/pypi/keyring](https://pypi.python.org/pypi/keyring) operates

<comment><USER29> I would love to know more about this, but AFAIK OS secret stores are mostly a desktop-concept that requires a logged-in user (whose login password is used to decrypt the secret store). On a deployment server, you don't have those.

<comment><USER30> It should be easy to set up such a key store on server setup or startup. The downside is that, as always, if anyone has access to the user, they can decrypt the keys.

</comment></comment></comment><comment><USER31> we are in a similar situation and there is another approach I'd like to research. In order to have a distributed properties I was considering using something like consul[1] or etcd[2] which have some control access and load the required variables from upstart scripts

[1] [https://www.consul.io/](https://www.consul.io/)

[2] [https://github.com/coreos/etcd](https://github.com/coreos/etcd)

</comment><comment><USER32> You could still store your secret keys in ENV but encrypt them. Only your program has the method to decrypt them so in the case of an ImageMagick sub process it would access only your encrypted secret key with no knowledge to decrypt it.

Same thing while debugging : only the encrypted key is printed.

<comment><USER33> You would need the key to decrypt somewhere also not in your code.

<comment><USER32> Why not in the code ? As I see it we're not trying to fend off Mr Über attacker, just avoid that your keys become public by mistake.

And instead of a secret key which is easily searchable, your method could just do some substitutions, something a bit more complicated than a Caesar cypher. Yes it's really weak but it beats an unencrypted secret key.

I know security minded people are not gonna like it, but until we have a real battle tested solution it's better than nothing.

A determined attacker will almost always win against our best defenses. I think we have to do our best to make their job hard, but at one point we have to accept that offense is really easier than defense.

</comment></comment></comment><comment><USER34> Ansible has a neat feature, called Ansible Vault, which lets you encrypt sensitive files. This in combination with dotenv-deployment works pretty well for our Rails Apps. The only thing I'm worried about is someone gaining unauthorised access to our serves and thus being able to read all the credentials stored inside the .env file especially the username & password to our externally hosted db. Probably the only way to prevent this would be "to properly secure your server" and the use of an IDS? Anyone has any experience with someone hacking their servers and successfully preventing e.g. a db dump? In this particular case, how easy would it be to stop attackers in their tracks?

<comment><USER35> If someone gets sufficient access to your server to read arbitrary files it is 99.95% possible that they also have sufficient access to just read your DB username and password straight out of the Rails application's memory. (One method, among many, would be "Attach a debugger to it." For a graphic example of what is possible with debuggers, in a format slightly easier for Rails devs to understand, see: [https://github.com/ileitch/hijack](https://github.com/ileitch/hijack))

</comment></comment><comment><USER36> I typically store the env _name_ in the environment, and then use that in my apps to build a path to the file containing secrets (e.g. /etc/{mycompany}/{environment}/myapp.conf). The file is locked down by ACLs or permissions.

<comment><USER37> If I set _name_ to "../../blackhat/myhackedconfig/" will that cause problems?

</comment></comment><comment><USER8> There's a (not widely publicized) feature of Linux that enables secure key storage inside the kernel: [https://www.kernel.org/doc/Documentation/security/keys.txt](https://www.kernel.org/doc/Documentation/security/keys.txt) Storing keys in the kernel has some advantages -- your key will never get inadvertently swapped to disk etc.

It's been too long since I used it to remember the details, but I believe process-private keys are one of this API's features.

</comment><comment><USER38> I got bit by env vars a few years back, but due to performance issues in getenv() and ended up writing a whole bunch of PHP magic to ship config files safely and fast.

With pecl/hidef, I can hook a bunch of text .ini files into the PHP engine and defines constants as each requests comes in.

Originally, it was written for a nearly static website, which was spending a ridiculous amount of time defining constants, which rolled over every 30 minutes.

Plus those .ini files were only readable to root, which reads it and then forks off the unprivileged processes.

But with the hidef.per_request_ini, I could hook that into the Apache2 vhost settings, so that the exact same code would operate with different constants across vhosts without changing any code between them.

Used two different RPMs to push those two bits so that I could push code & critical config changes as a two-step process.

And with a bit of yum trickery (the yum-multiverse plugin), I could install two versions of code and one version of config, and other madness like that with the help of update-alternatives.

That served as an awesome A/B testing setup, to innoculate a new release with a fraction of users hitting a different vhost for the micro-service.

I'm rambling now, but the whole point is that you need per-request/per-user config overlay layers, for which env vars are horrible, slow and possibly printed everytime someone throws some diagnostics up.

</comment><comment><USER39> Please consider the environment before printing this config?

</comment><comment><USER40> We had to migrate our software from single tenant (per machine) to multiple tenant for our cloud offering, on a 11 year old code base.

We used Michael's trick: environment variables pointing to config files works _unbelievably_ well if you ever need to implement a multiple tenant cloud offering.

So apart from the security aspect, there's the aspect that it is a more versatile design.

</comment><comment><USER41> We've had good success with distributing our secrets using a GPG-encrypted file that we put in /etc, not in the source code tree. We then use an ENV setting to point the app to the file. This gives us good flexibility (because one server can have multiple GPG files if we want, such as alpha/beta/gamma) and good encryption.

<comment><USER20> How do you manage the decryption key?

</comment></comment><comment><USER42> Clearing your environment variables after reading them, and only passing the ENVs required to perform the new task are pretty basic security measures. This was pretty common practice in the 90's, and then I was hoping that would be one of the lessons out of ShellShock.

</comment><comment><USER43> Ok I'm confused by 'environment variable' vs files. How does one set an environment variable without putting it in a file on the particular server. Or by 'file' in this article (and the 12 factor one) do they mean a file that in source control?

<comment><USER44> The article means 'file in source control' \- the specific context is that the author is one of the co-founders of Heroku where there is a whole separate (really nice) system for handling 'config variables' as part of your app deployments separate from source control.

<comment><USER45> You can also run foreman if you're not on Heroku. Put your environment variables in a `.env` file. The environment variables get sourced only to the environment of that process and not to the __whole__ system

</comment></comment></comment><comment><USER46> _1\. It 's easy to grab the whole environment and print it out (can be useful for debugging) or send it as part of an error report for instance._

If you have software in your deployment that will send "error reports" to untrusted third parties then you have bigger problems than your shell environment.

 _2\. The whole environment is passed down to child processes_

If you don't trust your child processes then you have bigger problems than your shell environment.

 _3\. External developers are not necessarily aware that your environment contains secret keys._

And?

I'm not sure what you mean by "external developer" and what you expect them to do with your environment. E-Mail it out when an error occurs?

If you tolerate that kind of developer on your project then you.. oh well, see above.

<comment><USER47> Is it so inconceivable that one might trust error reports to third parties, but not secret keys?

<comment><USER46> Either you exercise control over what you send, or you don't.

This has nothing to do with your choice of configuration method.

</comment></comment></comment><comment><USER48> why not just split it up with an OTP, that you store in the code (or a file), then the other half in the environmental variable. combine in code (or include the file). seems like that would work. (you need both parts.)

I think this article is a response to people's practice of keeping API keys as an environmental variable so as to keep them off of the filesystem (or at least what git sees and checks in) so that they don't accidentally publish them, as happened in that article article where some gem he was using to respect .gitignore didn't work for some reason.

would this work as a solution?

</comment><comment><USER49> ENV propagation to unwanted targets is a legit point.

Our most common crash report scenario is the airbrake gem sending crash reports from our rails app to errbit. I can confirm airbrake gem does not post any sensible env data.

Of course, this is only a good news for that specific case, others apps may transfer environment, and we can't just wonder for each app installed "what will it ever send ?".

</comment><comment><USER50> I wrote a library to handle mixed configuration values by using asymmetric RSA encryption [1].

[1]: [https://github.com/jacobgreenleaf/greybox](https://github.com/jacobgreenleaf/greybox)

<comment><USER17> There are lots of problems with this, not the least of which being:

• Configuration files can be trivially forged (rsa without signing)

• Many configuration files can be trivially decrypted without the key (rsa use on potentially big files)

• Keys can be trivially recovered in multiple ways (global variable, ptrace)

Users might be tricked into using your library despite the fact it offers them no real security except false security.

I recommend placing a warning that it is not intended to be used by anyone at any time.

<comment><USER51> Your criticisms don't seem to make much sense...

* Preventing forgery/tampering is an orthogonal issue and can be done by intrusion-detection software.

* "trivially decrypted without the key" \-- How? The size of the file is not going to make any difference here.

* Of course, the key can be recovered if you have the ability to ptrace. What's your point? That's going to be true of any solution out there.

Why don't you make some constructive criticism instead of being obnoxious.

<comment><USER17> Writing software that may run in a potentially hostile environment should be done with great care, and a thorough analysis of what you are actually protecting against.

This is a job for people who take programming seriously, not amateurs who can't be bothered to read the documentation of the modules they are using, e.g.

[http://stuvel.eu/files/python-rsa- doc/usage.html](http://stuvel.eu/files/python-rsa-doc/usage.html)

Note especially the bits about signing RSA, and how to use it to encrypt files. Doing raw RSA on strings longer than 245 bytes is unwise, and inventing new protocols for RSA is unwise. That the author does these things is strong evidence that the author is not demonstrating "great care".

If the author believes forgery/tampering is orthogonal and/or protection from in-process attacks, then the author should state that. That's part of the analysis step.

> Of course, the key can be recovered if you have the ability to ptrace. > What's your point? That's going to be true of any solution out there.

Nonsense. If you delete the key from memory, it is obvious that someone cannot use ptrace to recover it afterwards. Detailing what is at risk, and what is not at risk is part of the analysis step.

<comment><USER51> > Writing software that may run in a potentially hostile environment should be > done with great care, and a thorough analysis of what you are actually > protecting against.

The first section of his documentation states what the purpose of the module is and what's it is trying to protect against. The use of RSA there is pretty reasonable, so I don't know why you're being so hard on him. It also talks about how this project is a variation on another project, so it's not like he is going off half-cocked and implementing something crazy.

> This is a job for people who take programming seriously, not amateurs

Everyone starts out as an amateur. You can either be an internet know-it-all that wants to show off how little you know or you can provide constructive feedback.

> who can't be bothered to read the documentation of the modules they are > using, e.g. [http://stuvel.eu/files/python-rsa- > doc/usage.html](http://stuvel.eu/files/python-rsa-doc/usage.html) > Note > especially the bits about signing RSA, and how to use it to encrypt files. > Doing raw RSA on strings longer than 245 bytes is unwise, and inventing new > protocols for RSA is unwise. That the author does these things is strong > evidence that the author is not demonstrating "great care".

Did you bother to read the documentation yourself? It directly talks about encrypting large files. Yes, it's true that trying to encrypt more data than is supported for a key size will leak information, which is why implementations throw an error if you try to do that. The usage documentation you pointed to discusses that and provides options to cope with it. But, in this case, he is not even encrypting the whole file, just the values of certain properties, which are probably going to be small enough to not require any extra measures.

And, again, what does signing have to do with how RSA is being used in greybox?

> If the author believes forgery/tampering is orthogonal and/or protection > from in-process attacks, then the author should state that. That's part of > the analysis step.

They did state the scope of the project and there is really no need for them to go into deep detail about deployment. Are you going to criticize him for not pointing out that the whole system needs to be secured from tampering? Of course not, so stop acting like a douchebag.

>> Of course, the key can be recovered if you have the ability to ptrace. What's your point? That's going to be true of any solution out there. > Nonsense. If you delete the key from memory, it is obvious that someone cannot use ptrace to recover it afterwards. Detailing what is at risk, and what is not at risk is part of the analysis step.

You have to ask, where did the key come from in the first place? The private key file has to exist somewhere that is accessible on the box so that the process can read it in the first place. If someone has ptrace, they can probably read a file as well.

Ultimately, it's about the level of risk people are willing to live with. For what greybox seems targeted at, it's encrypting properties in files that are committed to a repo and then using a private key that is only available on certain machines to read that property. For some use cases, that is probably a perfectly fine level of security and better than what is being done in some cases anyways.

<comment><USER17> > You have to ask, where did the key come from in the first place?

It is sensible to type it in while the system is still in single-user mode.

If you left the private key in a file that is right next to your encrypted configuration file, then it remains as I stated previously: No security except false security.

> Everyone starts out as an amateur.

This is not the forum for an education on programming. A library that states it was written as a learning exercise with a request for criticism will be treated that way. A library proposed to solve problems recognised in the linked article will not.

> Ultimately, it's about the level of risk people are willing to live with.

People are notoriously bad at recognising and evaluating risk.

<comment><USER51> > If you left the private key in a file that is right next to your encrypted > configuration file, then it remains as I stated previously: No security > except false security.

Shut up and read the goal of the project already. It is trying to protect secrets that are stored in a repo and it achieves that goal.

Secrets on a deployed host will always be in the clear on that host, it's just a fact of life. Many barriers can be put in place, but at the end of the day, a program will always need access to the plaintext version of the secret at some point.

> It is sensible to type it in while the system is still in single-user mode.

No it isn't. Services have to restart all the time, saying that a human has to be ready to type in a password at any moment is not practical.

> This is not the forum for an education on programming.

But it is a forum for you to post invalid criticisms of a project and act like a dick? That's bullshit. This is "hacker news", it's a perfectly fine place for a technical discussion. If you thought there were problems with the project and this wasn't the right place to discuss it, then file issues on the github project.

> A library that states it was written as a learning exercise with a request > for criticism will be treated that way. A library proposed to solve problems > recognised in the linked article will not.

There is no difference, you're just trying to justify your bad behavior.

</comment></comment></comment></comment></comment></comment></comment><comment><USER52> How do you suppose I do this in AWS where I have several auto-balanced servers? It kind of forces you to put it in environment variables.

<comment><USER3> Why is that? Isn't that exactly the same problem whether you're using environment variables or a config file?

<comment><USER52> Because all the instances spin up with a fresh file system, but you can specify the environment variables in the AWS console.

</comment></comment></comment><comment><USER53> while i agree that storing api keys in the code repository is not the best idea, i am curious about the suggestion of moving it into chef configs.

wouldnt that, in turn, also be stored in a code repository, likely accessible in the same way as the main coe repo? then, this feels like a non-solution to me.

<comment><USER54> Its a trap thinking you have to store all the config info in Chef(recipes, data bags, etc). Its easy to call out to other services for config info to render templates with.

Mreinsch's s3 reco is a good example. I use this method for storing extra role secrets for AWS.

It's good to keep in mind the words Morpheus when dealing with Chef(and all this stuff really). Free your mind.

</comment></comment><comment><USER55> While I could simply tell you to blank out ENV vars once you've internalized them, I will instead write an infinitely long essay on how they are "considered harmful" that contributes absolutely nothing back to society.

<comment><USER47> This is not always an option; the argument applies as well to using tools written by others that expect secrets to be provided in an environment variable. The AWS SDK is a popular example. While it will also happily read credentials from a configuration file, or allow them to be explicitly passed, it's a popular method and is the only one that is consistent across the various SDKs that AWS provides.

</comment></comment><comment><USER56> I created a quick gem (which you shouldn't install) that demonstrates having some untrusted code in your app which will post all of your environmental variables to a 3rd party server: [https://github.com/tibbon/env_danger](https://github.com/tibbon/env_danger)

Now, of course no one would install and run this... but I could imagine someone accidentally typing the name of a Gem wrong, someone accepting a bad PR (a sub-dependancy perhaps even doing so?), etc and somehow something untrusted getting in there. Yes, that means you have other problems, but it isn't outside the realm of possibility that accidental access like this is had.

Just because it _shouldn 't_ happen, doesn't mean it will never happen.</comment>


Apple is regressing to their 1990s identity - <AUTHOR> https://triosdevelopers.com/jason.eckert/blog/Entries/2019/8/1_Apple_is_reverting_to_their_1990s_disposition.html <comment><USER2> From the headline I thought this was going to be about them having too many SKUs, but after reading I see it's just the standard techie tropes about overpriced and closed systems.

The thing is that consumers (clearly) don't care about that stuff. There is no such thing as "overpriced" as long as the item is selling. Consumers determine the price of something based on the single factor of "what they are willing to pay". If Apple can sell devices at that price, and consumers are willing to pay it, then it is by definition not overpriced.

Opennes is also overvalued for techies. While I am on the side of openness myself, the vast majority of consumers don't care about it. They only care about the value they are getting from the product. There might be a few people who really want to crack open the case, but they do not have any significant presence in the market.

What consumers _do_ care about is feeling good about their purchase, and the Apple of the 1990s had so many products and was so unfocused that none of the products were good, and consumers felt bad when they bought them.

The SKU problem is the same as today. Now you have half a dozen iPads to choose from, and a number of laptops that all seem to be the same except for half an inch between models. No matter what you pick, you leave the store with a sense of FOMO, not knowing if you really picked the right model. That is really what Steve did — you went in and bought the only option they gave you, and you felt confident you got the right one.

<comment><USER3> Apple could sell the iPhone for a million dollars, and I'm sure at least one person would buy it.

Similarly, they could sell the iPhone for $10k and maybe sell a million of them.

I guess "overpriced" is a subjective term. But if Apple sold the iPhone at cost, Apple could certainly sell a lot more of them. If Apple sold it for a margin more in line with other manufacturers, Apple could still probably sell a lot more...

Apple doesn't care that much about total shipments, though. They care more about total revenue & profits.

I think it's fair for people to call something overpriced even if tons of people are buying it -- especially if there's an argument to be made that a substantial portion of consumers are buying an alternative based mostly on price, and that the comparison product has a much higher margin than the alternative.

Again, this doesn't make it a bad business decision. If there's one thing I guarantee Apple knows more than anyone on Hacker News, it's what the optimal price is for their product to meet their business objectives.

<comment><USER4> Apple could not sell the phone at a price more in line with other manufacturers, because they spend a shit ton of money on R&D and other costs that the other manufacturers don't bother to do — because they know Apple will do it, and they can leach off the work Apple has done.

There will always be lower priced competitors who are happy to be in a race to the bottom. Apple is smart to recognize that they cannot do this, for it would spell the doom of the company.

Luxury brands don't do races to the bottom. To do so would violate their entire reason for existence.

Sure, you might want that Ferrari or Lamborghini to be given to you on a silver platter, or sold to you for just $10.00 each, but do you really honestly expect them to be that stupid?

<comment><USER5> A minor point, Apple's R&D spend is significantly lower as a percent of budget compared to most of the market. I found this article really interesting:

[https://www.ped30.com/2019/03/10/defense- apples-14-billion-r...](https://www.ped30.com/2019/03/10/defense- apples-14-billion-rd-budget/)

Edit for context: in 2018, 11.6bn or 5.1% of revenue. Compare to Amazon it's half as many dollars and 1/3 the percent.

<comment><USER6> What is it compared to other phone manufacturers? Percentages don't really matter as much as raw numbers. You can only throw so much money at any technology without having a diminishing rate of return.

<comment><USER7> It's difficult to say what they spend on Phone R&D, but Samsung spends about 11-12% on R&D in general. Huawei and Google clock in around 15% by public numbers and Intel for comparison sits about 20%. Microsoft is somewhere around 12-13%.

Apple's total R&D spending is well below their contemporaries as a % of revenue.

<comment><USER6> Samsung has a lot more products and verticals as does Google.

Looking at all of the money that Google spends on research - they still make 90% of their revenue on ad sales and have had a string of failures and also rans.

No one can seriously argue that Apple's ARM processor designs aren't top notch, they just took over Intel's modem division and they still depend on Intel for much of their computer hardware - except for the T2 chips that are part of their ARM designs

What else do you propose that Apple spend money on?

Horace Deidu just posted a graph on twitter showing that just their services revenue is larger than all of Apple's revenue a decade ago.

<comment><USER7> I'm not suggesting anything about Apple's quality of engineers or what they should spend money on. I am only observing that their R&D spending is below other companies that are considered in the same class or industry as a percent of revenue.

Their spending (as percent) is approximately 1/3 of other phone makers, 1/3 of software developers, or 1/4 of other chipset manufacturers.

These numbers are all very rough of course because, as you point out, all of these companies work in multiple sectors and R&D spending is not disclosed in that much detail.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> No they're not. They're a different company serving a different, and now global audience. Consider that Apple is more than 5% of America's entire GDP, and 1% of the world's entire GDP. There are ~1 billion people in the Apple ecosystem and that number is an under-estimate. When Apple chooses to add Sapphire as a material to the Apple Watch or iPhone, they affect global prices for the raw material.

People still don't get it. It's not a game of pattern matching with their past. Not only have they and their customers changed, but the world has changed. Computing has changed.

These articles always fail to consider context in favor of the easy, selective, myopic pattern matching.

Don't take this to mean that Apple is above criticism. They're not. But articles like this are lazy.

<comment><USER9> I think the criticism that a closed ecosystem is myopic and a competitive disadvantage is a fair one, though. Apple used to have a monopolistic stronghold on smartphones, but that is no longer the case. As in the nineties, a walled garden is going to look less appealing if there are cheaper, more open competitors offering as-good or better hardware.

Outside of phones, their MacBooks are teetering on the edge of no longer being competitive. The _sole_ reason I most recently bought a MacBook instead of a different PowerBook with a tablet screen is that Linux support for tablet screens is still lacking, and my desire for POSIX overrode my desire for a touch screen. The next time I buy, I doubt that will be true of Linux. Either Apple will come late to the game with touch screen laptops (rather exemplifying the article's point that their hardware lags the competition), or they won't, and it will make far more sense to get a faster third party tablet book and put a free OS on it. And I doubt the average customer will care as much about POSIX as I do, but again, as in the nineties, serious developers aren't going to take Apple seriously forever if this keeps up.

<comment><USER4> Apple still owns most of the profit in smartphones, and they don't really care about so-called market share that really just applies to the loss leaders.

</comment></comment></comment><comment><USER10> _...the release of the Mac OS X operating system, which was essentially a rebranded version of NeXTSTEP UNIX. Because Mac OS X was UNIX, it was fundamentally open..._

I truly appreciate the UNIX foundation and heritage of OSX, but "fundamentally open" is not a phrase I have ever associated with either or with UNIX.

OSX is UNIX the way AIX, Irix, Solaris, HPUX, etc. are (were) UNIX. None of these are open in any meaningful sense (Solaris being an exception, but that's relatively recent.) The author seems to under the impression that because OSX is UNIX, it's suddenly in the same category of openness as the BSDs and Linux.

 _To tech-minded people in the 2000s, Apple was no longer this closed, proprietary, expensive tinker toy. They were a decent UNIX workstation manufacturer that fostered openness._

UNIX workstation? Yes. Fostering openness? No. The Apple of the 00's was essentially, and arguable remains, a closed, proprietary, expensive, consumer oriented UNIX workstation.

 _But since then, it seems as if Apple has continually made decisions to move back in time to the 1990s. Rather than adopting open standards in their operating systems, they started focusing on developing their own, intended to work within their own ecosystem only._

Maybe I'm missing the point. There certainly are Apple hardware changes and trends that I've not been happy about. I also recognize that there are software changes and standards deviations that are unfortunate. However, the idea that Apple was somehow a bastion of openness, and that their OS was open and now isn't seems inaccurate.

<comment><USER11> The Darwin kernel and many other macOS components are open. Just take a look at [https://opensource.apple.com/](https://opensource.apple.com/) Are they perfect? No... but a lot further along than the Unix of old.

</comment></comment><comment><USER12> I think this article accurately identifies Apple's moves towards a more closed ecosystem, but I don't think there's any particular reason to believe that "the future is open". Unlike in the past, Apple has a much broader ecosystem, to the point where you can use only Apple-approved products and services for almost everything you would want to do, so interoperability doesn't matter as much. Additionally, as computers have become more widespread, the demand for customization has declined significantly. Sure, there are still people that want to repair their computer, or install Linux, or customize it in some other way, but as a share of the overall market, it's a really tiny percentage.

As long as smartphones remain most people's primary form of computing, I don't really see Apple beig hurt in any significant way. They've effectively created a monopoly on iOS software, so that developers have to put up with the experience, no matter how bad it gets, if they want to make any money. And until some major new technology comes along that Apple doesn't have, it doesn't seem like there's any reason for consumers to abandon Apple's ecosystem in favor of something else.

<comment><USER13> Right. Apple became "open" as a competitive move. Catered to the tech folks with the UNIX-based OS.

Then when they developed a new competitive moat in iPhones, they were able to move back to closed.

<comment><USER14> And that was just an accident, if Jobs were at Be instead, not sure if they would have bothered with anything UNIX related.

Even NeXT wasn't that open to UNIX, for them that was just a way to have a foot on the young workstation market, NeXTSTEP hardly leveraged POSIX for the framework APIs.

</comment></comment></comment><comment><USER15> I actually like that Apple moves at its own pace and doesn't wait for standards to evolve. If you are willing to adopt the Apple ecosystem, it's a bliss. If you can't then just ignore them. I've been on both sides of the fence during the last decade.

<comment><USER16> Apple waits till a company does something then copies it. Even their Window system features have been copied from Linux. Their hardware is overpriced and you are essentially just paying for an Apple logo and aesthetic pushed by a marketing company. It is like the Nike of computers.

<comment><USER17> NeXTStep (September 18, 1989) predates Linux (September 17, 1991)and it's window managers. I'd suggest you also look at Apple's work on ARM processors. They were first to 64 bit in that space.

<comment><USER18> Apple was one the companies that created ARM as well.

"The company was founded in November 1990 as Advanced RISC Machines Ltd and structured as a joint venture between Acorn Computers, Apple Computer (now Apple Inc.) and VLSI Technology."

</comment></comment></comment></comment><comment><USER19> Major difference between the 90s and now is the market dominance that Apple has with their iOS platform. As a company having a closed ecosystem which they can push in their own direction. The most important piece is that it drives their revenue either from app purchases, in-app purchases, subscriptions, and Apple services.

I'm speaking mostly about their mobile platform... Mac laptops / desktops are another thing... Specifically, I think the lack of a reasonably affordable desktop solution for developers is kind of a bumper. We need upgradability and openness for drivers to make it viable. There are use cases for a less expensive desktop that developers would buy.

<comment><USER20> Does the Mac Mini not satisfy this need? At least for the desktop requirement, I'm aware it may not satisfy your driver requirements.

<comment><USER21> The Mac Mini is sort of limited by the lack of any graphics horsepower and the lack of stand-alone displays from Apple. You also can't get one with a really powerful CPU.

It's a cool machine, but the tiny form factor is fairly limiting.

<comment><USER8> Mac Mini supports Thunderbolt 3 which has enough throughput to run a powerful external GPU with minimal (~10%) efficiency loss.

<comment><USER21> That's fair. From what I hear, thunderbolt GPUs are a fair bit more finicky than internal PCIe ones, so for a desktop I'd still say having an internal GPU is better, but it should at least be a reasonably good workaround.

It's a bit sad to trade reliability, GPU performance, tidiness (since the external enclosure adds more boxes and wires and power supplies), price, and CPU power just for a smaller core computer though.

It gets even worse when you want a couple of big HDDs which would have just gone in drive bays with a traditional computer. With the mac mini, you'd have to add even more expensive external enclosures to your desk, which is expensive and messy. Suddenly, instead of a nice self-contained smallish desktop, you have an impressively small core machine box, with a wire to your GPU box (which has to be on top of the desk due to the short length of thunderbolt cables), a wire to your HDD box, and you still have the slower CPU.

I don't really mean to say the Mac mini is a poor choice, it probably fits a bunch of desktop use cases reasonably well. It's just not as optimal as it could be.

To illustrate how a real small and powerful desktop from Apple could've been: I'm using a really small (though not as small as the mac mini) Fractal Design Node 304 [0], with a 2.5 slot width, full length GPU, a 3.5" drive, two 2.5" drives, an m.2, and a standard ITX card with regular RAM and CPU slots. I have a 1080Ti and an i7 6700k in it with no thermal issues. Apple could've made a similarly expandable machine in a smaller form factor with better thermals and looks, but they... don't.

[0]: [https://www.fractal-design.com/home/product/cases/node- serie...](https://www.fractal-design.com/home/product/cases/node- series/node-304-black)

<comment><USER4> If Apple could do it, then so can other companies. So, where are the other companies that manufacture the Not-Apple Super Mac Mini that you're talking about?

EDIT: More importantly, where are the other companies that are selling billions of dollars worth of this kind of hardware?

<comment><USER21> I don't see how other companies are relevant? There's a lot of people selling bigger computers with a lot of power and expand ability, so there's clearly a market for that. I showed that it's not that hard to make a computer with that expandability, while not making a big tower computer; that it's not a binary choice between a powerful big tower and a really limited tiny mac mini-style computer. It also wasn't my comment's main point.

</comment></comment></comment></comment></comment></comment></comment><comment><USER22> Well, it's a perspective from tech outsiders looking down their noses on Apple, I guess. Macs had a role to play in the 90s, albeit the most interesting platforms were Unix and Linux.

<comment><USER14> The most interesting platforms were Atari ST, Amiga, PC, Macs and BeOS.

UNIX were interesting camouflaged as Irix and NeXTSTEP.

Linux interesting bit was trying not to toast the monitor while attempting to get X working at all.

</comment></comment><comment><USER23> "And in today's age of open source, it's clear that the future is open"

Apple's is the third most valuable company in the world. You'd have to be delusional to think the future is open.

Pack it in, fellow tech-priests, we lost this one.

<comment><USER24> Not sure I agree on this one... a significant portion of the internet, and other devices (that aren't thought of as computers) are running Linux underneath. Android being the most popular user facing variant (custom UI/UX).

There's a lot to be said for open platforms. I'd also be surprised if given a few years that WebAssembly doesn't bring more open application options, even to closed ecosystems like Apple's iThings.

</comment></comment><comment><USER25> I have to agree with this article. I've been a Mac User since the iBook G3 running both OS9 and OSX. Working as a video editor at the time Final Cut Pro was revolutionary and you could open up your G4/G5 and add RAM and hard drives.

But recently I have to shell out $3000 USD for something with limited ports, a touchbar without a clear use case, poorly designed keyboards, and constant upcharging for docks, dongles and services.

I get where they are going... appeal to pros who don't care how much stuff costs and consumers who will pay anything for apple devices.

</comment><comment><USER26> From article: "Rather than adopting open standards in their operating systems, they started focusing on developing their own, intended to work within their own ecosystem only."

I'm glad they did. MacOS is more clean and secure than Windows and Linux, and is a primary driver for Apple hardware sales. You can make Linux _almost_ as secure, with enough tinkering, but it is not out of the box experience. Think Gatekeeper code signing.

<comment><USER27> Are there even good examples of "intended to work within their own ecosystem only"? I'm constantly surprised to the extent Apple embraces openness and interoperability (compared to my personal expectation of what they would do). It seems to me that they just totally ignore it in favor of building a "perfect" (by their own definition) product.

If anything, I would describe that behavior as "extreme NIH syndrome".

<comment><USER26> You lost me here. What behaviour?

<comment><USER28> Not Invented Here.

</comment></comment></comment></comment><comment><USER29> Apple today is not the company it was 10 years ago, let alone 20 years ago. Comparison is not useful. People buy equipment for different reasons from different levels of expertise. Some people like to hack their hardware, some don't. I've grown out of hacking hardware and software and prefer high availability. Like cars, I guess, buy a Ford or a Merc. Customer's choice.

</comment><comment><USER30> I disagree with one part.

The 1990s was when Apple didn't have Jobs for many years. Then Jobs came back and saved the company. Now Apple is without Jobs again for many years.

But saying Apple chose closed solutions? That's classic Jobs. He ended the open clones program and OpenDoc etc. and brought it all in-house. The only thing Apple ever did that was really open under Jobs was probably bringing NextStep UNIX onboard!

<comment><USER31> > The only thing Apple ever did that was really open under Jobs was probably > bringing NextStep UNIX onboard!

Nit: Jobs did not make this decision as he was not part of the company when it was made.

<comment><USER11> Late 1990's Apple was basically mired in technical debt. The original classic Mac OS was over a decade old and on very shaky foundations. No memory protection, cooperative multitasking (until OS 8, I think?), etc. Their own internal OS projects (Copeland, Taligent) were never completed.

NextStep was like night and day. It breathed new life into Apple.

</comment></comment></comment><comment><USER32> > … Apple stores told customers that small repair issues would cost thousands > of dollars to fix (to encourage them to buy a new Mac).

Reference? That seems to be attributing malice when bad design (or design trade-offs) are more likely.

<comment><USER33> [https://www.cbc.ca/news/thenational/complete-control- apple-a...](https://www.cbc.ca/news/thenational/complete-control-apple- accused-of-overpricing-restricting-device-repairs-1.4859099)

</comment></comment><comment><USER34> Apple is regressing to a Prada or Fendi identity. Now that they've become a "lifestyle brand" whose revenues come largely from Veblen goods they have much less incentive to foster technical excellence, engage with the technical community, or market products for use by professionals.

At least 1990s Apple users were computer fans in an era when that was a rare thing. Today, strippers and drug dealers carry iPhones (and are proud of it).

</comment><comment><USER35> My job is deploying and configuring Macbooks at reasonable scale (2000-5000). This article is nonsense.

</comment><comment><USER36> And this time Jobs can't come back to save them... Well, unless he truly was techno jesus.

<comment><USER24> Steve at GamersNexus is Tech Jesus...

</comment></comment><comment><USER37> I wish this site support reader mode! Hard to read on my iPhone.

<comment><USER38> Reader is working in Firefox nightly mobile for me, is it different for iPhone?

</comment></comment><comment><USER39> Does Apple even matter anymore?</comment>


Front end career path - <AUTHOR> Hello, I want to have a career as a front end developer, is there a known path? What's the directions? Should I go into UX / Design as well? <comment><USER2> What is your background? Do you have any particular kind of development you'd like to get into?</comment>


Uber Wedding - <AUTHOR> https://blog.uber.com/uberwedding

<comment><USER2> I wish this was available last year. I used Uber for my wedding in DC and got something like 10 cars at a time two times. Turned out fine and everybody loved it. They felt very VIP with the SUV's. We tried to work with Uber on organizing this but didn't seem interested. Luckily everything went well.

</comment><comment><USER3> Looks like around ~500 weddings* will take place over Pride Weekend in SF. So sponsoring 1% on demand looks very doable.

That violinist Gabi Holzwrath is incredible (she has a "Royals" cover shot in Palo Alto) - [http://gabiviolin.com/](http://gabiviolin.com/)

*Based on previous data: [http://www.sfgate.com/lgbt/article/Huge-crowd-ecstatic-vibe-...](http://www.sfgate.com/lgbt/article/Huge-crowd-ecstatic-vibe-at-SF-Gay-Pride-Parade-4639361.php#page-2)

<comment><USER4> Gabi's amazing. She's also dating Travis:

[http://recode.net/2014/05/28/playing-billionaire-for-the- bil...](http://recode.net/2014/05/28/playing-billionaire-for-the-billionaires- a-violinists-ironic-wink/)

</comment></comment><comment><USER5> Lol I first thought this was a joke, checked my calendar, nope, no 1st of April, damn, must be real then. Jokes aside, I think it is pretty cool! Curious to know what kind of price are we talking about here. Then personally I'd never use the whole package, I've very specific envy for my honeymoon etc. But having the transportation and big ceremony logistic handled for you sounds pretty amazing to me! Can't wait to read experience from people actually doing it!

</comment><comment><USER6> Note that if you do the math with the constraints of one unique violinist and nonzero travel time, there can only be a maximum of 5-6 weddings in the given time window.

<comment><USER7> Of course. It's a promo stunt to get headlines, not an actual service. Wait and see how suspiciously young and attractive all the couples will be.

</comment></comment><comment><USER8> Why enter into a marriage contract so lightly?

<comment><USER9> I'd assume it's aimed at folks who have already decided to get married, but dont' know when or how they want to do it, and want "a unique experience".

</comment></comment><comment><USER10> Building up the market for Uber Divorce. But I wouldn't wait until next year.

</comment><comment><USER11> I wish this was a joke. 2014: the year the tech industry jumped the shark.</comment>


Poor Lonely Computer: Prince's Misunderstood Relationship with the Internet - <AUTHOR> http://www.npr.org/sections/therecord/2016/03/08/469627962/poor-lonely-computer-princes-misunderstood-relationship-with-the-internet <comment><USER2> > Infamously, Prince managed to take down a YouTube clip of himself performing > a cover of Radiohead's "Creep" at the Coachella music festival in 2008, > despite the band's lead singer Thom Yorke making it very clear who the song > actually belongs to. The law does not provide a great deal of clarity in > these cases, unfortunately.

I'm not sure I understand what the actual basis of copyright is in a situation like this.

I believe the videographer would hold a copyright claim to the original video recording, the artist Prince would claim copyright to his own rendition of the song and that specific performance, and Radiohead, Thom Yorke, or Radiohead's record label would collectively hold mechanical and phonorecord copyrights to the original song according to the song's history and their agreements.

It's trivial for Prince to obtain a compulsory mechanical license to perform a cover which would have been done prior to performance. It's also true that Radiohead may have the ability to prevent the video's distribution, depending on the interpretation of copyright law, and I find it also reasonable that Prince would have a copyright claim to the performance that he or his record label could have it removed. I certainly don't think Thom Yorke could supersede Prince's request to have the recording removed, just because he wrote or performed the song originally.

There is some information here, but it's still limited in scope: [https://en.wikipedia.org/wiki/Compulsory_license#United_Stat...](https://en.wikipedia.org/wiki/Compulsory_license#United_States_2)

I wouldn't believe what's written on issues of copyright law in offhand observations.

<comment><USER3> The law seems clear to me, tbh. There is a pipeline: writers -> performers -> recorders. In absence of specific contracts, all three groups have to agree in order to _enable_ distribution/reproduction of the final work in its entirety; if one says no, the whole thing is called off. Writers can still re-sell their writing, performers can re-perform it and so on, but the original recording just cannot be released.

(Obviously, in most cases there _are_ actual agreements hammering out various angles, like recorders or performers actually being configured as "work for hire" in order to take them out of the copyright pipeline altogether. But that's another story.)</comment></comment>


Tcpcrypt - <AUTHOR> http://tcpcrypt.org/ <comment><USER2> I really like when people acknowledge the difference between passive and active attackers. I really, really want there to be more passive protection by default without requiring every computer/node/server to have a trusted certificate.

I really would like to see a better handling for this in the case of https as well. I want a way to see a mechanism that a site can offer to provide passive communication protection but where the site does not guarantee its identity, thus meaning it's possible for a MitM attack if you're willing to accept that risk.

<comment><USER3> Just because you don't have signed certificates you can still protect against MitM attacks. Your browser just has to remember what the certificate was the first time, and alert you it if changes.

Sound familiar? It should, ssh(1) does this by default.

<comment><USER4> The first time you connect to any SSH server, the connection can be hijacked. People used to do this for sport at Usenix.

Why would anyone accept this weakness with their bank account? My mom barely understands the lock icon.

<comment><USER3> What sort of person goes to a conference like Usenix and connects to an external server _for the first time_? I've been to a dozen conferences, all of whom I've used ssh at, and I've _never_ connected to an external box for the first time.

<comment><USER4> I can't imagine what possible point you could be trying to make. Am I making this up or not? I doubt I am, but who cares? The issue with first-connection security in SSH is a fact, not an opinion.

<comment><USER3> Yes, first-connection security is not an option. But the vast majority of connections are not first connections.

If I ssh to a new box at home, then go to Usenix and ssh warns me that the host key changed I'll have protected against MitM attacks, even if the original connection wasn't authenticated.

<comment><USER4> That model works passably well for SSH connections. You make perhaps tens of those connections every day, from perhaps several devices.

It doesn't work at Internet scale. It's too insecure. It's very unlikely that key continuity is going to replace PKI in HTTPS.

Do I have strong opinions about PKI vs. key continuity? No. All I'm saying is that it's not a panacea. SSH-style key continuity is not the global solution for the certificate warning Firefox is annoying you with.

You realize that Firefox already does this, right? Just hit "add exception" when the dialog pops up. Look! It works just like SSH!

<comment><USER5> Arguably, the right way of doing it is to use both. PKI to auth first connect, remember the chain to prevent bad CAs from giving certs people pretending to be BoA.

<comment><USER6> Why not abandon central key authorities and go distributed? Bring social networks and the web-of-trust together.

      "3 of your friends have said that they trust this
      certificate from Amazon.com. Do you want to accept it?"

<comment><USER7> If I had a dollar for every time a friend clicked a .exe email attachment, I'd be a very wealthy man. I damn sure don't trust my friends to verify the security of a cert.

<comment><USER8> I have some security-savvy friends (who I'd trust) and some not so smart friends (who I don't trust on this subject). So, the obvious idea is to put weight coefficients on WoT digraph edges. But I have a feeling that this would be too complicated to manage.

<comment><USER9> Your mom would trust you and then her friends would trust her, then they'd all get burned because she meant to click No one time and it would all be your fault.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER4> This is basically useless as-is for things like banking security, because the security of SSL is premised on inherent resistence to "active" (MITM) attackers.

<comment><USER10> The stuff that matters has already been secured. It looks like tcpcrypt is designed to encrypt everything else.

<comment><USER11> Correction: the stuff that _really_ matters (like banks) has already been secured.

The other stuff still matters a lot, especially when users often share passwords between secure and non-secure websites. Or when companies offer a single sign-on service without mandatory encryption (I'm looking at you Facebook and Twitter)

This would be better than nothing (if it were ubiquitous), but I'd rather everything use SSL.

<comment><USER3> > I'd rather everything use SSL

That's not going to happen as long as browsers treat the continuum of security like this:

        BEST: Oh nice, a SSL connection with a CA signed cert
        COOL: A normal HTTP connnection
        OMGWTFBBQ: ZOMG SOMEONE HAS A SELF SIGNED SSL CERT THE
                   SKY IS FALLING LET'S PRESENT 10 CLICK
                   THROUGH DIALOGS BEFORE THE USER CAN OPEN
                   THE BLODDY SITE

As opposed to:

        BEST: Oh nice, a SSL connection with a CA signed cert
        COOL: Oh nice, a SSL connection, but no CA signing, treat like HTTP UI-wise
        COOL: A normal HTTP connection, show the user the traffic isn't encrypted.

<comment><USER4> The reason your browser goes "ZOMG" when it sees a self-signed certificate is that there is no way to distinguish the "'avar made himself a handy self- signed certificate" case from the "someone has substituted a random certificate into my Bank of America login". Think about it.

Long story short: don't hold your breath waiting for browsers to chill out about self-signed certs.

<comment><USER3> Yes there is, think about it :)

Bank of America has a CA signed cert, so when you go there you display a golden "YOU ARE SECURE, CITIZEN" banner at the top with a lock icon etc.

But if someone _doesn't_ have a CA signed SSL cert you treat it no differently than normal HTTP traffic.

Then you train users not to submit their financial information to sites that don't have a CA signed SSL certificate (as indicated by the giant "YOU ARE SECURE, CITIZEN" banner).

You have to do that _anyway_ , when I go do my online banking I visit a plain http site and _then_ click on my private banking link that takes me to a https site.

The easiest way for a MitM to spoof that would be to just direct the user to a plain HTTP site when he goes to do his private banking. So even today users have to understand that they must submit this sort of data over SSL _and_ that the cert involved has to be CA-signed.

<comment><USER4> Think harder. How does Firefox know, when it sees a self-signed certificate, that _that site_ wasn't supported to have a certificate signed by a CA?

It doesn't, and can't.

If the "ZOMG" warning --- which, let's just keep calling it that, because I think it's funny that you think one of the most important pieces of UI in Internet security is a "ZOMG" measure --- didn't exist, attackers could substitute their own "self-signed" certificates for Bank of America's Verisign-signed cert when hijacking www.bankofamerica.com.

<comment><USER3> Yes, it doesn't, and can't. But I'm saying that it doesn't matter.

When people visit "foo-bank.com" the easiest way to do a MitM is to simply do a _http_ MitM. Then you don't have to forge any SSL certificates, or rely on the browser not yelling enough.

The _only_ way to guard against that is to train users to recognize that they shouldn't be sending money through a non-CA SSL connection, as indicated by their browser with a friendly "Secure" icon somewhere.

Thus, if browsers treated non-CA signed SSL connections just like normal HTTP connections, i.e. just used encryption, didn't present any "secure" banners etc. you wouldn't make things any less secure.

Non-CA signed SSL traffic is just as secure as unencrypted HTTP traffic (i.e. not), and browsers should treat both of them equivalently.

<comment><USER4> This is why your bank doesn't let you make withdrawals from your account on port 80.

You need to keep re-reading this sentence: there is no difference to the browser between a TLS connection bearing a self-signed cert and a TLS connection that was supposed to bear a CA-signed cert but isn't. _It can't tell the difference_.

"But that untrusted connection is no less secure than an HTTP connection!", you retort. Wrong. The HTTP connection isn't _lying to you_ about how secure it is. The HTTPS connection with the bogus cert is, as far as Firefox is concerned, lying. And for most users, most of the time, it's right. Something is wrong with the connection.

I understand that it drives you nuts that there is collateral damage to this security warning. Yes. There is collateral damage. You get a very noisy exception dialog even when you wanted a self-signed cert. But the alternative to that dialog allows attackers to spoof Citibank, and the browser vendors have all decided that your self-signed cert is less important than Citibank.

<comment><USER12> _there is no difference to the browser between a TLS connection bearing a self-signed cert and a TLS connection that was supposed to bear a CA-signed cert but isn't._

As long as my browser can tell the difference between a Citibank with a CA- signed cert and a Citibank without one, why should I care about the exact manner in which the wrong Citibank doesn't have what it should? What makes encryption without authentication so much more dangerous than plaintext?

Edit: You talk about forged certificates a lot. Do you mean that browsers acts as if certificates are for a secret club only, and anyone not a member (CA) but using the technology is infringing? I could believe that, as it jives with how I initially understood the business model. The problem, then, is that non- members like to authenticate too, and it is assumed they will do so via other channels and that their users are technologically sophisticated enough to import the certificates - when the key continuity thing is actually more popular.

Since the browsers check your credentials anyway, I see no point in getting paranoid about seeing an unfamiliar signature. That's only a deception if your guards consider the mere existence of a signature as proof of authorization - that is, if they're human. If they always check, there is no point in bluffing, and so an unrecognized signature should not be considered treachery.

<comment><USER4> I'm kind of confused by your questions, but: to be valid, a certificate needs to be signed by a CA for whom your browser holds a root CA certificate.

Without authentication, anybody who controls routing, ARP, or the DNS can break your encryption; they just stick themselves in the middle.

<comment><USER12> The original question wasn't "why is encryption without authentication a bad idea"; it was "why is it worse than nothing". The only thing I can come up with is that some users look for _https_ instead of the newer security banners.

The additional question was "is a non-CA-signed certificate irrelevant to authentication, or is it a forgery" - my opinion would be the former, browsers seem to think the latter.

It is my understanding that adding trusted third parties is possible for the client, but considered to be only for advanced users, and that adding security exceptions for self-signed certificates is unexpectedly common. I further consider the terminology unfortunate (servers with valid certificates are not certified, they are authenticated).

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> A lot of the SSL vs. SSH discussion on here is just demonstrating the fact that there is no one-size-fits-all solution for authentication.

The point of tcpcrypt is to get the best security possible under any setting, so it can be used with both SSL- and SSH-like settings. See slide 5 of the talk on the web site:

<http://tcpcrypt.org/tcpcrypt-slides.pdf>

One thing I haven't seen discussed yet is that fact that come October, the EKE patent is going to expire, which means that all of a sudden it's going to be legal to do strong authentication using only human-chosen passwords. Strong password authentication is desperately needed, because people overwhelmingly both chose week passwords and don't think carefully about where they send those passwords.

Somewhat independent of tcpcrypt, section 4.3 of the tcpcrypt Usenix paper suggests a nice and simple secure password-authentication protocol. Deploying such a protocol would make a huge difference, except... what are you authenticating? You can prove possession of a password, but this doesn't actually protect you unless the authentication is tied to session traffic, and you are authenticating communication endpoints. SSL, IPSec, and even SSH don't provide adequate hooks for doing this (though SSH would be easier to retrofit than the other two). Tcpcrypt does.

So the way to view this is that in the absence of authentication, tcpcrypt will be vulnerable to MITM. But as soon as you go to authenticate yourself to a server (by typing a password or verifying a certificate), the authentication will fail, and the MITM will no longer be able to deceive the user.

</comment><comment><USER14> There's not much point in encryption unless you know who you're talking with.

<comment><USER15> Mark Handley makes that very point on page 3 of his paper here (sorry about the PDF):

<http://www.cs.ucl.ac.uk/staff/m.handley/slides/tcpcrypt.pdf>

"Encryption without authentication is like meeting a stranger in a dark alley."

However, on subsequent pages he writes about ways to do authentication over tcpcrypt using the session ID, including signing it with an SSL certificate or using HMAC with shared passwords. As he says, "many different authentication schemes [are] enabled by the session ID concept." The tcpcrypt.org site itself says "Tcpcrypt abstracts away authentication, allowing any mechanism to be used, whether PKI, passwords, or something else."

Perhaps these mechanisms can help us gradually avoid the problems with both central authority schemes and key continuity schemes, but I haven't thought about it or researched it enough yet to know. I have a love-hate relationship with SSL, and when I hear about hijacked CAs and even see root certs in the name the various governments in Firefox, I get the chills. But I can appreciate SSL's strengths. On the other hand, I really like SSH's key continuity, but I also appreciate some of its difficulties on the web. As an experiment, I recently deleted _all_ CAs from Firefox and started approving web sites by exception one by one.

Does anyone here have a good handle on how tcpcrypt's "abstracted" authentication schemes might thread that needle, simultaneously avoiding the difficulties and pitfalls in both camps?

</comment></comment><comment><USER16> Sounds like the ubiquitous opportunistic encryption that was a goal of FreeS/WAN.

<http://www.freeswan.org/> _2004/03/01_

 _FreeS/WAN is no longer in active development. Although we've created a solid IPsec implentation widely used to construct Virtual Private Networks, the project's major goal, ubiquitous Opportunistic Encryption, is unlikely to be reached given its current level of community support._

<comment><USER10> I looked into FreeS/WAN in the early days (1997?) and they made two architectural mistakes: You had to put some special records in your reverse DNS zone (which most people can't do) and it introduced a 30-second delay the first time you contacted each non-FreeS/WAN IP address (which made Web browsing completely unbearable). These misfeatures protected against MITM attacks, but they also ensured that FreeS/WAN would never be deployed.

</comment></comment><comment> X-Istence I can't find this anywhere, and I looked in the source code as well, what is the license for this?

The Linux kernel module is GPL, however there is no license on the rest of the source code. I have no idea if I can use any part of this and port it over to FreeBSD as a kernel module for example.

<comment><USER17> _port it over to FreeBSD as a kernel module for example._

Just for the record: As long as I'm the FreeBSD security officer, this is not going to be in the FreeBSD source tree.

(I can't stop you from building and distributing a kernel yourself, of course.)

<comment><USER18> Thank you. My thoughts were something along the lines of, who do I trust more, the well vetted kernel tcp stack, or this unknown modification to my tcp stack in the name of security. It's hard enough making sure the normal stack doesn't have any issues (and, in my understanding, why Windows/OSX/Solaris have taken parts of the BSD TCP stack)

</comment></comment></comment><comment><USER8> Why reinvent the wheel when we already have IPsec?

<comment><USER19> "Why introduce this HTML/HTTP thing when we have Gopher? Don't re-invent the wheel!"

Re-inventing the wheel is good. It's the only way we'll ever get better wheels.

<comment><USER20> Indeed; for all we know, our wheels are oblong if not _triangular_. Without reinventing the wheel sometimes, you'd never come up with stuff like this: <http://en.wikipedia.org/wiki/Mecanum_wheel>

</comment></comment></comment><comment><USER21> i really don't like any aspect of this at all. so, my encryption is not guartanteed, i don't know if it's working, it doesn't cover all network traffic, and isn't shipped by default with any operating systems. i'm never going to use this and i'm never going to recommend it to anyone for any purpose. (sorry, i drank a jug of haterade this morning)

<comment><USER10> Obviously the goal is to be built in to the OS. Flipping your objection around, you could say that with tcpcrypt more of your traffic will be encrypted than is now; it's no worse than the status quo.

<comment><USER21> what's the point of "more encryption than you have now" if it can be disabled by mitm (this includes the 'wireless networks' cited as a good reason to use it) and you don't even know if it's working? if i want to use encryption, i want to _know its encrypted_. there is no point otherwise.

an example: i'm using an unencrypted network and plaintext protocol. if there's no attacker on the network, my data is "safe." if there is an attacker, my data is effectively compromised.

if i'm using this solution around the same network connection and there is no attacker on the network, my data is safe. if there is an attacker, they'll see it's this lame attempt at encryption, disable it through mitm, and my data is effectively compromised.

in a real life setting i can't depend on this to secure my data. however, ssh, openvpn, ipsec and other solutions provide _assured_ encryption (unless you screw up the configuration). you don't even need a CA with ssh or openvpn - copy your keys or certs by a usb key once and you immediately have a strong defense against mitm.

i'd love to see sites provide a secure encryption alternative to SSL which allows for out-of-band transfer of secure keys and 1-to-1 authentication to prevent a nation's clandestine operations from peeking at my traffic. that probably won't happen though. in the meantime i protect my last-mile access with a secured tunnel; i just pray SSL is strong enough to not be attacked at a hop from my tunnel endpoint to the site.

<comment><USER3> The point is to upgrade the connections that are unencrypted _now_ to use encryption. A MitM can only insert his own data into your dialog, he can't passively eavesdrop on an existing encrypted connection.

<comment><USER4> This is the waxed-mustache damsel-tied-up-on-the-railroad-tracks notion of Internet attackers, who, getting a sudden bee in their bonnet to torment 'avar from Hacker News, leap upon his connections only to find that, drat!, 'avar had enabled tcpcrypt and all his connections are safeguarded.

The real Internet attackers owned up your ISP 2 years ago, and on the real Internet you originate hundreds of new connections across that owned-up Internet every minute. The security negotiation on any "old" connection is irrelevant. All that matters is the security of each new connection. If they're safe, the protocol works. If they're not, the protocol is broken.

<comment><USER3> Nobody said anything about "old" connections in this thread. wmf mentioned how encrypting everything (even if you don't know who's at the other end) is "no worse than the status quo".

Protocols that don't use encryption now aren't broken, and they could be slightly improved by transparently using encryption, because at least you'd deter passive sniffing.

<comment><USER4> If you and a friend exchange certificates, TLS protects you from most governments, including US domestic law enforcement.

If you and a friend set it up, tcpcrypt protects you from people who don't know to MITM TCP connections.

<comment><USER3> Yes, and if we meet and exchange one-time pads we'll be even more secure.

However neither that nor TLS "work out of the box: require no configuration, [and] no changes to applications".

<comment><USER4> No, it's going to be about as hard for (say) the FBI to break TLS as it is for them to break an OTP; either way, it isn't happening.

Can you say that for tcpcrypt? Of course not.

I don't know what your second sentence even means. I didn't do anything to configure TLS. What did you have to do?

<comment><USER3> I'm citing the design aims of Tcpcrypt, from their website.

Not everything uses HTTP, a bunch of things like Torrent, IRC etc. use unencrypted protocols by default, and you have to explicitly add support to each one for encryption. Either by adding SSL support to the programs themselves, or by setting up a tunnel.

That's not the same as using opportunistic encryption that can happen at the kernel level. You could _also_ do that with SSL to achieve the same aims, but the point is that it's _opportunistic_ and happens without further userspace configuration.

<comment><USER22> Can you really imagine someone going to all the trouble to sniff your traffic - and then giving up at that point because you have tcpcrypt enabled, given that it's trivial for them to perform a downgrade attack?

So it ends up being opportunistic encryption, that's enabled when you don't need it and disabled when you do. It's just a security blanket.

<comment><USER3> Tcpcrypt is aimed at passive attacks. Not everyone who has the power to listen in and perform a passive attack can modify the traffic and execute an active attack.

Even when you can do an active attack it's not trivial in practice. The user my get suspicious if they've previously been able to initiate a tcpcrypt connection but can't do so now, and if you do this on a big scale (e.g. government sanctioned sniffing at an ISP) you'll probably be found out.

<comment><USER21> can you give me an example of a connection that can be passively sniffed and _not_ injected into? unless you have some wacky physical media which has no Tx, if you can see their traffic at the very least you send spoofed packets to the destination or source. if you're on the source's LAN you just spoof DNS and/or ARP for either the default gateway or the destination. if you're on the destination's LAN you can spoof the destination or do packet injection. if you're in between either LAN you can arguably do any damn thing you like, depending on network topology and routes. but i don't see a case where i could see the traffic and not do something to either downgrade the connection, hijack it or mitm it.

so they're risking their data on an uncertain possibility that a user might catch on that i've been downgrading their sessions and stealing everything? once you explain this to a user, do you think they'll really trust it?

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER23> The performance comparison to SSL is not really fair, since tcpcrypt does not offer security against passive attackers.

<comment><USER24> You haven't read the site, have you?

> If, however, a Tcpcrypt connection is successful and any attackers that > exist are passive, then Tcpcrypt guarantees privacy.

<comment><USER23> Good catch. I meant to say that tcpcrypt is vulnerable to active attacks, rather than passive.

The point is that it is not a useful comparison to say that tcpcrypt is 36x faster than SSL, when it offers a weaker level of security.

<comment><USER13> If you use X.509 server authentication with 2,048-bit RSA keys, tcpcrypt offers about a 25x speed-up over SSL for equivalent security. (Actually slightly better, since tcpcrypt offers forward secrecy while, in the benchmark, SSL does not.) The key optimization is batch signing, where a single RSA signature can authenticate a bunch of connections at once. There are graphs showing this in the paper and talk slides.

</comment></comment></comment></comment><comment><USER22> How serious can they be about ubiquitous encryption, if they can't even be bothered enabling HTTPS on their site?

</comment><comment><USER25> They don't look very trustworthy to me.</comment>