4 ms·

SSH uses ephemeral keys. It's not enough to have the private key and listen to the bytes on the wire, you have to actively MITM the connection. A github employe

SSH uses ephemeral keys. It's not enough to have the private key and listen to the bytes on the wire, you have to actively MITM the connection. A github employee who has access to the private key and enough network admin privileges to MITM your connection already has access to the disk platters your data is saved on. Regarding the secrecy of the data you host at github, you should operate under the assumption that a sizeable number of github employees will have access to it. You should assume that it's all sitting unencrypted on several different disk platters replicated at several different geographically separated locations. Because it is. One of the things that you give up when you host your private data on the cloud is controlling who and under what circumstances people can view or modify your private data. If the content of the data is enough to sink you/your company without remedy you should not store it on the cloud.

ajross 4y ago
Exactly. Host keys are about authentication, not connection security. Presumably the upthread comment is trying to say that "ssh communication with github could have been subject to an undetectable MitM attack by an attacker with access to this key"[1], which isn't remotely the same thing as "all communication with GH since the founding of the company has to be considered compromised". [1] Which is sort of tautological and silly, because that's true of all sites and all host keys. What the comment was trying to imply was that the choice of storage of this key invalidates any trust we might have in GitHub/Microsoft regarding key management, and that therefore we shouldn't trust them. Which is also tautological and silly. Either you trust them or you don't, that's not a technological argument.
snowwrestler 4y ago
Agreed; GitHub documentation refers to repo “visibility,” not “security,” and that is an intentional distinction. When we signed on with GH as a paying customer over a decade ago, they were quite clear that private repos should not be considered secure storage for secrets. It’s not encrypted at rest, and GitHub staff have access to it. It takes only a few clicks to go from private to public.
- shdjhdfh 4y ago
  It is encrypted at rest: https://github.blog/changelog/2019-05-23-git-data-encryption-at-rest/ https://github.blog/changelog/2019-05-23-git-data-encryption...
  - Perseids 4y ago
    Not criticizing you, your technical correction is valid, but the discussion is besides the point. "Encryption at rest" is basically meaningless for something like GitHub. Not being able to pull out a hard drive in a data center and read it at home has been table stakes for some time. But how few people are able to do that anyway? A blog post like the above is just necessary to tick some boxes to comply with this or that regulation. The real question is how many services are able to access the data live and how many support and debug interfaces (indirectly) allow you to read it. Measure GitHub's success in securing the secrecy of private repos in how few employees can breach it without causing alarms. Even without cynicism I would be surprised if it was their main concern. Data integrity is far more important for code. (There are notable exceptions, of course. If applicable, don't put it in the cloud!)
adql 4y ago
You shouldn't commit unencrypted secrets to git anyway, public or private, on-site or in cloud. There are plenty of tools to either keep them encrypted (we just use simple GPG, but our team is small) or just auto-generate and never show to user in the first place (various key vaults that can be used from automation like HashiCorp's Vault)
- nwallin 4y ago
  The person I'm replying to is arguing that their source code itself is the secrets they're trying to protect.
est31 4y ago
I would also add that your ability to pretend to be the client to the server is also limited, if ssh key based client authentication is used. This means that even if the host key is leaked, an attacker will not be able to push in the name of the attacked client. The attacker will be able to pretend to be the server to the client, and thus be able to get the pushed code from the client (even if the client just added one patch, the attacker can pretend to be an empty repo server side and receive the entire repo. If ssh token based auth is used, it's different of course, because then the server gets access to the token. Ideally Github would invalidate all their auth tokens as well. The fun fact is that a token compromise (or any other attack) can still happen any point in the future with devices that still have outdated ssh keys. That's a bit unfortunate as no revocation mechanism exists for ssh keys... ideally clients would blacklist the ssh key, given the huge importance of github.
- westurner 4y ago
  WKD also lacks key revocation and CT Certificate Transparency. E.g. keybase could do X.509 like Certificate Transparency. : $ keybase pgp -h NAME: keybase pgp - Manage keybase PGP keys USAGE: keybase pgp <command> [arguments...] COMMANDS: gen Generate a new PGP key and write to local secret keychain pull Download the latest PGP keys for people you follow. update Update your public PGP keys on keybase with those exported from the local GPG keyring select Select a key from GnuPG as your own and register the public half with Keybase sign PGP sign a document. encrypt PGP encrypt messages or files for keybase users decrypt PGP decrypt messages or files for keybase users verify PGP verify message or file signatures for keybase users export Export a PGP key from keybase import Import a PGP key into keybase drop Drop Keybase's use of a PGP key list List the active PGP keys in your account. purge Purge all PGP keys from Keybase keyring push-private Export PGP keys from GnuPG keychain, and write them to KBFS. pull-private Export PGP from KBFS and write them to the GnuPG keychain help, h Shows a list of commands or help for one command $ keybase pgp drop -h NAME: keybase pgp drop - Drop Keybase's use of a PGP key USAGE: keybase pgp drop <key-id> DESCRIPTION: "keybase pgp drop" signs a statement saying the given PGP key should no longer be associated with this account. It will **not** sign a PGP-style revocation cert for this key; you'll have to do that on your own. /?q=PGP-style revocation cert https://www.google.com/search?q=PGP-style+revocation+cert https://www.google.com/search?q=PGP-style+revocation+cert : - "Revoked a PGP key, is there any way to get a revocation certificate now?" https://github.com/keybase/keybase-issues/issues/2963 https://github.com/keybase/keybase-issues/issues/2963 - "Overview of Certification Systems: X.509, CA, PGP and SKIP" ... - k8s docker vault secrets [owasp, inurl:awesome] https://www.google.com/search?q=k8s+docker+vault+secrets+owasp https://www.google.com/search?q=k8s+docker+vault+secrets+owa... https://github.com/gites/awesome-vault-tools https://github.com/gites/awesome-vault-tools - Why secrets shouldn't be passed in $ENVIRONMENT variables; though e.g. the "12 Factor App" pattern advises to parametrize applications mostly with environment variables that show in /proc/pid/environ but not /proc/pid/cmdline W3C DID supports GPG proofs and revocation IIRC: "9.6 Key and Signature Expiration" https://www.w3.org/TR/did-core/#key-and-signature-expiration https://www.w3.org/TR/did-core/#key-and-signature-expiration "9.8 Verification Method Revocation" https://www.w3.org/TR/did-core/#verification-method-revocation https://www.w3.org/TR/did-core/#verification-method-revocati... Blockerts is built upon W3C DID and W3C Verified Credentials, W3C Linked Data Signatures, and Merkel trees (and JSON-LD). From the Blockerts FAQ https://www.blockcerts.org/guide/faq.html https://www.blockcerts.org/guide/faq.html : > How are certificates revoked? > Even though certificates can be issued to a cohort of people, the issuer can still revoke from a single recipient. The Blockcerts standard supports a range of revocation techniques. Currently, the primary factor influencing the choice of revocation technique is the particular schema used. > The Open Badges specification allows a HTTP URI revocation list. Each id field in the revokedAssertions array should match the assertion.id field in the certificate to revoke. Re: CT and W3C VC Verifiable Credentials (and DNS record types for cert/pubkey hashes that must also be revoked; DoH/DoT + DNSSEC; EDNS): https://news.ycombinator.com/item?id=32753994 https://news.ycombinator.com/item?id=32753994 https://westurner.github.io/hnlog/#comment-32753994 https://westurner.github.io/hnlog/#comment-32753994 "Verifiable Credential Data Integrity 1.0: Securing the Integrity of Verifiable Credential Data" (Working Draft March 2023) > Security Considerations https://www.w3.org/TR/vc-data-integrity/#security-considerations https://www.w3.org/TR/vc-data-integrity/#security-considerat... If a system does not have key revocation it cannot be sufficiently secured.
steve1977 4y ago
> you should not store it on the cloud. Well, at least not without encryption that is under your control.
CHY872 4y ago
It's worth saying that GitHub also has GitHub AE, which has some requirements (e.g. 500+ heads) but is a lot better for paranoid administrators, offering stricter audit results (FedRAMP High is no joke), data residency, stricter auth requirements, etc etc. I'd _imagine_ that such an environment is deployed as an isolated managed GitHub Enterprise instance, and at the very least in that environment I'd expect all data to be secured encrypted at rest.
- deleted 4y ago
  [deleted]

ajross 4y ago

Exactly. Host keys are about authentication, not connection security. Presumably the upthread comment is trying to say that "ssh communication with github could have been subject to an undetectable MitM attack by an attacker with access to this key"[1], which isn't remotely the same thing as "all communication with GH since the founding of the company has to be considered compromised". [1] Which is sort of tautological and silly, because that's true of all sites and all host keys. What the comment was trying to imply was that the choice of storage of this key invalidates any trust we might have in GitHub/Microsoft regarding key management, and that therefore we shouldn't trust them. Which is also tautological and silly. Either you trust them or you don't, that's not a technological argument.

snowwrestler 4y ago

Agreed; GitHub documentation refers to repo “visibility,” not “security,” and that is an intentional distinction. When we signed on with GH as a paying customer over a decade ago, they were quite clear that private repos should not be considered secure storage for secrets. It’s not encrypted at rest, and GitHub staff have access to it. It takes only a few clicks to go from private to public.

shdjhdfh 4y ago
It is encrypted at rest: https://github.blog/changelog/2019-05-23-git-data-encryption-at-rest/ https://github.blog/changelog/2019-05-23-git-data-encryption...
- Perseids 4y ago
  Not criticizing you, your technical correction is valid, but the discussion is besides the point. "Encryption at rest" is basically meaningless for something like GitHub. Not being able to pull out a hard drive in a data center and read it at home has been table stakes for some time. But how few people are able to do that anyway? A blog post like the above is just necessary to tick some boxes to comply with this or that regulation. The real question is how many services are able to access the data live and how many support and debug interfaces (indirectly) allow you to read it. Measure GitHub's success in securing the secrecy of private repos in how few employees can breach it without causing alarms. Even without cynicism I would be surprised if it was their main concern. Data integrity is far more important for code. (There are notable exceptions, of course. If applicable, don't put it in the cloud!)

adql 4y ago

You shouldn't commit unencrypted secrets to git anyway, public or private, on-site or in cloud. There are plenty of tools to either keep them encrypted (we just use simple GPG, but our team is small) or just auto-generate and never show to user in the first place (various key vaults that can be used from automation like HashiCorp's Vault)

nwallin 4y ago
The person I'm replying to is arguing that their source code itself is the secrets they're trying to protect.

est31 4y ago

I would also add that your ability to pretend to be the client to the server is also limited, if ssh key based client authentication is used. This means that even if the host key is leaked, an attacker will not be able to push in the name of the attacked client. The attacker will be able to pretend to be the server to the client, and thus be able to get the pushed code from the client (even if the client just added one patch, the attacker can pretend to be an empty repo server side and receive the entire repo. If ssh token based auth is used, it's different of course, because then the server gets access to the token. Ideally Github would invalidate all their auth tokens as well. The fun fact is that a token compromise (or any other attack) can still happen any point in the future with devices that still have outdated ssh keys. That's a bit unfortunate as no revocation mechanism exists for ssh keys... ideally clients would blacklist the ssh key, given the huge importance of github.

westurner 4y ago
WKD also lacks key revocation and CT Certificate Transparency. E.g. keybase could do X.509 like Certificate Transparency. : $ keybase pgp -h NAME: keybase pgp - Manage keybase PGP keys USAGE: keybase pgp <command> [arguments...] COMMANDS: gen Generate a new PGP key and write to local secret keychain pull Download the latest PGP keys for people you follow. update Update your public PGP keys on keybase with those exported from the local GPG keyring select Select a key from GnuPG as your own and register the public half with Keybase sign PGP sign a document. encrypt PGP encrypt messages or files for keybase users decrypt PGP decrypt messages or files for keybase users verify PGP verify message or file signatures for keybase users export Export a PGP key from keybase import Import a PGP key into keybase drop Drop Keybase's use of a PGP key list List the active PGP keys in your account. purge Purge all PGP keys from Keybase keyring push-private Export PGP keys from GnuPG keychain, and write them to KBFS. pull-private Export PGP from KBFS and write them to the GnuPG keychain help, h Shows a list of commands or help for one command $ keybase pgp drop -h NAME: keybase pgp drop - Drop Keybase's use of a PGP key USAGE: keybase pgp drop <key-id> DESCRIPTION: "keybase pgp drop" signs a statement saying the given PGP key should no longer be associated with this account. It will **not** sign a PGP-style revocation cert for this key; you'll have to do that on your own. /?q=PGP-style revocation cert https://www.google.com/search?q=PGP-style+revocation+cert https://www.google.com/search?q=PGP-style+revocation+cert : - "Revoked a PGP key, is there any way to get a revocation certificate now?" https://github.com/keybase/keybase-issues/issues/2963 https://github.com/keybase/keybase-issues/issues/2963 - "Overview of Certification Systems: X.509, CA, PGP and SKIP" ... - k8s docker vault secrets [owasp, inurl:awesome] https://www.google.com/search?q=k8s+docker+vault+secrets+owasp https://www.google.com/search?q=k8s+docker+vault+secrets+owa... https://github.com/gites/awesome-vault-tools https://github.com/gites/awesome-vault-tools - Why secrets shouldn't be passed in $ENVIRONMENT variables; though e.g. the "12 Factor App" pattern advises to parametrize applications mostly with environment variables that show in /proc/pid/environ but not /proc/pid/cmdline W3C DID supports GPG proofs and revocation IIRC: "9.6 Key and Signature Expiration" https://www.w3.org/TR/did-core/#key-and-signature-expiration https://www.w3.org/TR/did-core/#key-and-signature-expiration "9.8 Verification Method Revocation" https://www.w3.org/TR/did-core/#verification-method-revocation https://www.w3.org/TR/did-core/#verification-method-revocati... Blockerts is built upon W3C DID and W3C Verified Credentials, W3C Linked Data Signatures, and Merkel trees (and JSON-LD). From the Blockerts FAQ https://www.blockcerts.org/guide/faq.html https://www.blockcerts.org/guide/faq.html : > How are certificates revoked? > Even though certificates can be issued to a cohort of people, the issuer can still revoke from a single recipient. The Blockcerts standard supports a range of revocation techniques. Currently, the primary factor influencing the choice of revocation technique is the particular schema used. > The Open Badges specification allows a HTTP URI revocation list. Each id field in the revokedAssertions array should match the assertion.id field in the certificate to revoke. Re: CT and W3C VC Verifiable Credentials (and DNS record types for cert/pubkey hashes that must also be revoked; DoH/DoT + DNSSEC; EDNS): https://news.ycombinator.com/item?id=32753994 https://news.ycombinator.com/item?id=32753994 https://westurner.github.io/hnlog/#comment-32753994 https://westurner.github.io/hnlog/#comment-32753994 "Verifiable Credential Data Integrity 1.0: Securing the Integrity of Verifiable Credential Data" (Working Draft March 2023) > Security Considerations https://www.w3.org/TR/vc-data-integrity/#security-considerations https://www.w3.org/TR/vc-data-integrity/#security-considerat... If a system does not have key revocation it cannot be sufficiently secured.

steve1977 4y ago

> you should not store it on the cloud. Well, at least not without encryption that is under your control.

CHY872 4y ago

It's worth saying that GitHub also has GitHub AE, which has some requirements (e.g. 500+ heads) but is a lot better for paranoid administrators, offering stricter audit results (FedRAMP High is no joke), data residency, stricter auth requirements, etc etc. I'd _imagine_ that such an environment is deployed as an isolated managed GitHub Enterprise instance, and at the very least in that environment I'd expect all data to be secured encrypted at rest.

deleted 4y ago
[deleted]