Content tweaks
This commit is contained in:
parent
540f26ccd6
commit
7d60463fd0
|
@ -2,8 +2,8 @@
|
||||||
|
|
||||||
Establishing trusted communication between members of your team is paramount
|
Establishing trusted communication between members of your team is paramount
|
||||||
not only to avoid potential security problems associated with phishing and
|
not only to avoid potential security problems associated with phishing and
|
||||||
impersonation, but also to make it possible to exchange potentially sensitive
|
impersonation, but also to make it possible to exchange sensitive information
|
||||||
information without having to rely on half-baked or insecure channels.
|
without relying on untrusted or insecure channels.
|
||||||
|
|
||||||
You should establish trusted communication guidelines as early as possible,
|
You should establish trusted communication guidelines as early as possible,
|
||||||
before you put down any code or bring up any servers.
|
before you put down any code or bring up any servers.
|
||||||
|
@ -44,28 +44,28 @@ Trust* to accomplish the same goal.
|
||||||
- S/MIME is very well supported in desktop software, therefore
|
- S/MIME is very well supported in desktop software, therefore
|
||||||
barriers to entry and use will be lower than with OpenPGP.
|
barriers to entry and use will be lower than with OpenPGP.
|
||||||
- Portable devices tend to have decent mail client support for S/MIME,
|
- Portable devices tend to have decent mail client support for S/MIME,
|
||||||
allowing to both read and write secure emails.
|
allowing to both read and send secure emails.
|
||||||
|
|
||||||
#### Main downsides of S/MIME
|
#### Main downsides of S/MIME
|
||||||
|
|
||||||
- Has poor acceptance in the open-source world, which relies a lot heavier on
|
- Has poor acceptance in the open-source world, which relies a lot heavier on
|
||||||
OpenPGP standards. If you will need to communicate with other teams of
|
OpenPGP standards. If you will need to communicate with other teams of
|
||||||
developers across the open-source realm, chances are they will not be using
|
developers across the open-source realm, chances are that they will not be
|
||||||
S/MIME and may ask you to to use OpenPGP instead.
|
using S/MIME and may ask you to use OpenPGP instead.
|
||||||
- Many globally trusted CAs only need someone to verify that they can receive
|
- Many globally trusted CAs only need someone to verify that they can receive
|
||||||
email sent to the email address being certified. If your team relies on
|
messages at the email address being certified. If your team relies on
|
||||||
external CAs, your trusted communication will be as weak as the password on
|
external CAs, your trusted communication will be as weak as the password on
|
||||||
some developer's inbox.
|
any given teammate's inbox.
|
||||||
- If you do NOT rely on external CAs, then you will need to bring up and
|
- If you do NOT rely on external CAs, then you will need to bring up and
|
||||||
maintain your own CA, which means extra work to ensure its security, plus
|
maintain your own CA infrastructure, which means extra work to ensure its
|
||||||
you will be placing ultimate trust into the person or persons maintaining
|
security, plus you will be placing ultimate trust into the person or persons
|
||||||
your CA infrastructure.
|
maintaining your CA systems.
|
||||||
|
|
||||||
#### Main upsides of OpenPGP
|
#### Main upsides of OpenPGP
|
||||||
|
|
||||||
- Does not rely on external trust entities. Every member of the project will
|
- Does not rely on external trust entities. Every member of the project will
|
||||||
maintain their own web of trust. You do not have to place ultimate trust
|
maintain their own web of trust. You do not have to run a CA, or place
|
||||||
into the person who runs your CA infrastructure.
|
ultimate trust into the person who runs your CA infrastructure.
|
||||||
- OpenPGP is well accepted across open-source development teams for securing
|
- OpenPGP is well accepted across open-source development teams for securing
|
||||||
email communication, to a much greater degree than S/MIME.
|
email communication, to a much greater degree than S/MIME.
|
||||||
- OpenPGP is used in many free software areas beyond just securing email, for
|
- OpenPGP is used in many free software areas beyond just securing email, for
|
||||||
|
@ -95,6 +95,12 @@ couple of detailed explanations:
|
||||||
- [PGP Web of Trust: Core Concepts Behind Trusted Communication][5]
|
- [PGP Web of Trust: Core Concepts Behind Trusted Communication][5]
|
||||||
- [PGP Web of Trust: How does it work?][6]
|
- [PGP Web of Trust: How does it work?][6]
|
||||||
|
|
||||||
|
Main takeaways should be:
|
||||||
|
|
||||||
|
- Never trust keys without any signatures on them
|
||||||
|
- Only use keys listed as "fully valid" for encrypted correspondence
|
||||||
|
- Use keyservers and refresh your public keys regularly
|
||||||
|
|
||||||
### Using the Web of Trust in your team
|
### Using the Web of Trust in your team
|
||||||
|
|
||||||
Once you understand the core concepts behind the OpenPGP Web of Trust, you'll
|
Once you understand the core concepts behind the OpenPGP Web of Trust, you'll
|
||||||
|
@ -105,20 +111,21 @@ trust.
|
||||||
#### Spinning the web
|
#### Spinning the web
|
||||||
|
|
||||||
Web of trust is established via signing your teammate's keys and assigning
|
Web of trust is established via signing your teammate's keys and assigning
|
||||||
them trust. The protocol calls for an in-person meeting where both parties
|
them owner-trust. The protocol calls for an in-person meeting where both
|
||||||
present documents validating their identities and exchange key fingerprints.
|
parties present documents validating their identities and exchange key
|
||||||
Here's an in-depth document describing the procedure:
|
fingerprints. Here's an in-depth document describing the procedure:
|
||||||
|
|
||||||
- https://www.phildev.net/pgp/gpgsigning.html
|
- https://www.phildev.net/pgp/gpgsigning.html
|
||||||
|
|
||||||
##### Yes, but what if they are 12 timezones away?
|
##### Yes, but what if they are 12 timezones away?
|
||||||
|
|
||||||
It is easy to set up a video session and have them show their identification
|
If the new addition to your team lives far away from everyone else and has no
|
||||||
papers to the camera. Obviously, this process is easier to subvert than with
|
easy means of travel, then it is acceptable to set up a video session and have
|
||||||
person-to-person meetings, but not by much. Unless you are an expert at
|
them show their identification papers to the camera. Obviously, this process
|
||||||
identifying various foreign or out-of-state identification documents, it would
|
is easier to subvert than with a person-to-person meeting, but not by much.
|
||||||
be easy for an attacker to create a convincing driver's license that you've
|
Unless you are an expert at identifying various foreign or out-of-state
|
||||||
never seen before.
|
identification documents, it would be easy for an attacker to print out and
|
||||||
|
laminate a convincing driver's license or government ID.
|
||||||
|
|
||||||
At any rate, this protocol is less about identifying a person's state-issued
|
At any rate, this protocol is less about identifying a person's state-issued
|
||||||
identity, and more about creating a communication channel that is equally as
|
identity, and more about creating a communication channel that is equally as
|
||||||
|
@ -149,7 +156,7 @@ and OpenPGP:
|
||||||
Best practice is to always sign your messages, unless you have a good reason
|
Best practice is to always sign your messages, unless you have a good reason
|
||||||
not to (usually for plausible deniability reasons). For OpenPGP, the
|
not to (usually for plausible deniability reasons). For OpenPGP, the
|
||||||
recommended mechanism for signatures is MIME-signing, as inline-signing tends
|
recommended mechanism for signatures is MIME-signing, as inline-signing tends
|
||||||
to clutter the message with OpenPGP headers and footers, which may annoy your
|
to clutter the message with OpenPGP headers and footers and may annoy your
|
||||||
correspondents.
|
correspondents.
|
||||||
|
|
||||||
#### When to encrypt
|
#### When to encrypt
|
||||||
|
@ -159,8 +166,9 @@ that you do not wish others to know about (passwords and other account
|
||||||
information, confidential details that should not leak to the public, etc).
|
information, confidential details that should not leak to the public, etc).
|
||||||
Chances are, your recipient has only configured their mail client to read
|
Chances are, your recipient has only configured their mail client to read
|
||||||
encrypted emails on their workstation and not on their mobile device, so
|
encrypted emails on their workstation and not on their mobile device, so
|
||||||
adopting a policy of "always encrypt by default" may annoy your recipients,
|
adopting a policy of "always encrypt by default" may annoy your recipients
|
||||||
especially if the contents are not confidential or sensitive (patches, lunch
|
when they can't read your message from the comfort of their couch, especially
|
||||||
|
if the contents are not confidential or sensitive (chitchat, lunch
|
||||||
invitations, bikeshedding discussions, etc).
|
invitations, bikeshedding discussions, etc).
|
||||||
|
|
||||||
**When encrypting, you should also sign the message** (unless you *do* need
|
**When encrypting, you should also sign the message** (unless you *do* need
|
||||||
|
@ -173,52 +181,50 @@ as it may be a [spear phishing][7] attempt.
|
||||||
|
|
||||||
## Trusting IM sessions
|
## Trusting IM sessions
|
||||||
|
|
||||||
Almost all development teams use some kind of instant messaging solution in
|
Almost all teams use some kind of instant messaging mechanism in order to
|
||||||
order to coordinate their activities in real time -- be it IRC, Hangouts,
|
coordinate their activities in real time -- be it IRC, Hangouts, Slack, or any
|
||||||
Slack, or any number of other means. If critical decisions are taken during
|
number of other means. If critical decisions are taken during such meetings,
|
||||||
such meetings, then you should ensure that they happen over trusted
|
then you should ensure that they happen over trusted communication channels.
|
||||||
communication channels.
|
|
||||||
|
|
||||||
### One-on-one chat
|
### One-on-one messaging
|
||||||
|
|
||||||
There is no lack of clients for instant messaging, and while most of them will
|
There is no lack of clients for instant messaging, and while most of them will
|
||||||
encrypt your conversations from the client to the server, the contents will
|
encrypt your conversations from the client to the server, the contents will
|
||||||
still be seen in cleartext by the service providers, and most likely logged in
|
still be seen in cleartext by the service providers, and most likely logged in
|
||||||
some fashion. In some cases, these conversations can be later retrieved by
|
some fashion. In some cases, these conversations can be later retrieved by
|
||||||
attackers, so if you need to ensure that the provider does not know about the
|
attackers, so if you need to ensure that the provider does not know about the
|
||||||
contents of your messages, you need to communicate via a protocol that offers
|
contents of your messages, you must take steps to communicate via a protocol
|
||||||
point-to-point encryption and verification.
|
that offers point-to-point encryption and verification.
|
||||||
|
|
||||||
The only widely used cross-client protocol for securing end-to-end
|
The only widely used cross-client protocol for securing end-to-end
|
||||||
communication is Off-The-Record messaging (OTR). It is easy to set up in most
|
communication is Off-The-Record messaging (OTR). It is easy to set up in most
|
||||||
desktop clients, and there are several mobile clients available for
|
desktop clients, and there are several mobile apps available for communicating
|
||||||
communicating on the go (just search for "OTR" and you should be able to find
|
on the go, just search for "OTR" and you should be able to find them (e.g.
|
||||||
them).
|
SecureChat, IM+).
|
||||||
|
|
||||||
As with email, merely encrypting your connections does nothing to assure that
|
As with email, merely encrypting your connections does nothing to assure that
|
||||||
the person you are talking to is who they claim they are. You will need to
|
the person you are talking to is who they claim they are. You will need to
|
||||||
verify your contacts via OTR's excellent verification protocols before you
|
verify your contacts via OTR's excellent verification protocols before you
|
||||||
trust the chat session to be secure.
|
trust the chat session to be secure.
|
||||||
|
|
||||||
You may choose not to bother with point-to-point encryption for chat sessions
|
If you choose not to bother with point-to-point encryption for chat sessions
|
||||||
with your team members, but you should firmly establish as a matter of policy
|
with your team members, then you should firmly establish, as a matter of
|
||||||
what kind of conversations are suitable for IM, and what should be only sent
|
policy, what kind of conversations are suitable for IM, and what should be
|
||||||
via secured email.
|
only sent via secured email.
|
||||||
|
|
||||||
**NOTE:** Google has, confusingly, called something else "Off-The-Record"
|
**NOTE:** Google has, confusingly, called something else "Off-The-Record"
|
||||||
conversations, which merely exclude your chat sessions from being logged in
|
conversations, which merely exclude your chat sessions from being logged in
|
||||||
your inbox, but they are not point-to-point encrypted, and are still known to
|
your Inbox, but they are not point-to-point encrypted, and are still known to
|
||||||
Google.
|
Google.
|
||||||
|
|
||||||
### Group chat
|
### Group messaging
|
||||||
|
|
||||||
There is currently no widely used mechanisms to set up perfectly secure
|
There is currently no widely used mechanisms to set up perfectly secure
|
||||||
multi-user group chat sessions with point-to-point encryption. You may
|
multi-user group chat sessions with point-to-point encryption. You may
|
||||||
sidestep this limitation by running your own multi-user chat server (IRC,
|
sidestep this limitation by running your own multi-user chat server (IRC,
|
||||||
Jabber, HipChat) and requiring that everyone both authenticates and connects
|
Jabber, HipChat) and requiring that everyone both authenticates and connects
|
||||||
via a trusted protocol (both IRC and Jabber offer TLS), but you will still
|
via a trusted protocol (i.e. TLS), but you will still have to trust the
|
||||||
have to trust the administrators of that server not to log or misuse your
|
administrators of that server not to log or misuse your data.
|
||||||
data.
|
|
||||||
|
|
||||||
Alternatively, simply establish a firm policy that only public conversations
|
Alternatively, simply establish a firm policy that only public conversations
|
||||||
are allowed in group chat and everything else should happen over secure email
|
are allowed in group chat and everything else should happen over secure email
|
||||||
|
@ -248,12 +254,12 @@ tampered with by an attacker.
|
||||||
The easiest is to just sign the tags -- which will help, however may not be
|
The easiest is to just sign the tags -- which will help, however may not be
|
||||||
sufficient depending on the nature of your project. More recent versions of
|
sufficient depending on the nature of your project. More recent versions of
|
||||||
git have introduced a way to sign each individual commit, which makes it
|
git have introduced a way to sign each individual commit, which makes it
|
||||||
significantly more difficult for an attacker to sneak in a malicious commit
|
significantly more difficult for an attacker to sneak in malicious code
|
||||||
into someone's tree. However, without proper checking done by code
|
into someone's tree. However, without proper checking done by project
|
||||||
maintainers, this will only make it tamper-evident, and not tamper-proof (in
|
maintainers, this will only make it tamper-evident, and not tamper-proof (in
|
||||||
other words, someone may sneak in a malicious commit, and the most you'll be
|
other words, someone may sneak in a malicious commit, and the most you'll be
|
||||||
able to do is exonerate a trusted developer, but not prevent the compromise
|
able to do is exonerate a trusted developer, but not prevent the compromise
|
||||||
from happening).
|
from going out to your users).
|
||||||
|
|
||||||
Signed commits also make merges and other branch operations more complicated,
|
Signed commits also make merges and other branch operations more complicated,
|
||||||
but not insurmountable. Please see the following in-depth document to learn
|
but not insurmountable. Please see the following in-depth document to learn
|
||||||
|
@ -280,13 +286,13 @@ entities.
|
||||||
|
|
||||||
To create a detached signature for a tarball, use the following command:
|
To create a detached signature for a tarball, use the following command:
|
||||||
|
|
||||||
gpg -ba tarball.tar.gz
|
gpg -ba tarball.tar.xz
|
||||||
|
|
||||||
This will create a file called `tarball.tar.gz.asc` which should be uploaded
|
This will create a file called `tarball.tar.xz.asc` which should be uploaded
|
||||||
to the release server.
|
to the release server.
|
||||||
|
|
||||||
Alternatively, if you only release via git, you may simply use signed git
|
Alternatively, if you only release via git, you may simply use signed git
|
||||||
tags and let packagers create their own tarballs from git.
|
tags and let packagers create their own tarballs from git itself.
|
||||||
|
|
||||||
## Securing infrastructure access
|
## Securing infrastructure access
|
||||||
|
|
||||||
|
@ -317,10 +323,10 @@ Then, run `gpgkey2ssh` command with that key ID:
|
||||||
|
|
||||||
gpgkey2ssh 80A407E7
|
gpgkey2ssh 80A407E7
|
||||||
|
|
||||||
This will produce the output that you can put into the `authorized_keys`
|
This will produce the output that you can use for the `authorized_keys` file.
|
||||||
file. This saves you the trouble of asking them to send you their ssh public
|
This saves you the trouble of asking them to send you their ssh public key,
|
||||||
key, and assures the key actually belongs to your team member since it's part
|
and assures that the key actually belongs to your team member since it's part
|
||||||
of their trusted OpenPGP key.
|
of their trusted OpenPGP master key.
|
||||||
|
|
||||||
## Checklist
|
## Checklist
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue