profile
viewpoint
Filippo Valsorda FiloSottile @Google, Go team Manhattan, NYC https://filippo.io Cryptogopher. Go security lead. @RecurseCenter alum. RC F'13, F2'17.

FiloSottile/age 3402

A simple, modern and secure encryption tool with small explicit keys, no config options, and UNIX-style composability.

FiloSottile/captive-browser 277

A dedicated Chrome instance to log into captive portals without messing with DNS settings.

Ceasar/staticjinja 195

Minimalist Python library for building static sites w/ Jinja2

FiloSottile/CVE-2016-2107 168

Simple test for the May 2016 OpenSSL padding oracle (CVE-2016-2107)

FiloSottile/BERserk 87

A Go implementation of the BERserk attack against Mozilla NSS ASN.1 parsing of PKCS#1 RSA signatures with e = 3. Complete of a certificate generation tool, works with CAs in the trust store.

FiloSottile/ed25519-dalek-rustgo 73

Wrapper for curve25519-dalek using rustgo, a technique to directly call Rust code from Go programs with near-zero overhead, meant to replace manually written assembly.

FiloSottile/gorebuild 53

Extract the import path of Go binaries and rebuild them. No more stale GOROOT.

FiloSottile/blockchainr 52

Exploiting ECDSA Failures in the Bitcoin Blockchain

benjojo/gophervista 46

It's like AltaVista, but for RFC 1436 Gopher sites

benjojo/traceroute-haiku 28

A thing you can traceroute and it gives you a haiku inside the trace

issue closedgolang/go

proposal: crypto/ed25519: change GenerateKey to return private key only

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://github.com/golang/go/wiki/Questions -->

What version of Go are you using (go version)?

<pre> $ go version go version go1.13.3 darwin/amd64 </pre>

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

<details><summary><code>go env</code> Output</summary><br><pre> $ go env

</pre></details>

What did you do?

  • Consistency needed: Change GenerateKey() to return only private key with error because it seems awkward that it returns both public key and private key while NewKeyFromSeed() returns only private key. In addition, it is so confused for someone who are not familiar with crypto/ed25519 package
  • I know there might be a huge side effect when standard package is changed, but my opinion is that it worth modifying it right now, considering the current increase of gophers. As more gophers mean that more go code will be, this is perfect time to change it
  1. As-is
// GenerateKey generates a public/private key pair using entropy from rand.
// If rand is nil, crypto/rand.Reader will be used.
func GenerateKey(rand io.Reader) (PublicKey, PrivateKey, error) {
	if rand == nil {
		rand = cryptorand.Reader
	}

	seed := make([]byte, SeedSize)
	if _, err := io.ReadFull(rand, seed); err != nil {
		return nil, nil, err
	}

	privateKey := NewKeyFromSeed(seed)
	publicKey := make([]byte, PublicKeySize)
	copy(publicKey, privateKey[32:])

	return publicKey, privateKey, nil
}
  1. To-be
// GenerateKey generates a private pair using entropy from rand.
// If rand is nil, crypto/rand.Reader will be used.
func GenerateKey(rand io.Reader) (PrivateKey, error) {
	if rand == nil {
		rand = cryptorand.Reader
	}

	seed := make([]byte, SeedSize)
	if _, err := io.ReadFull(rand, seed); err != nil {
		return nil, nil, err
	}

	privateKey := NewKeyFromSeed(seed)
	return privateKey, nil
}

<!-- If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best. -->

What did you expect to see?

  1. Better coding experiment. No more confusion in package document(https://pkg.go.dev/crypto/ed25519?tab=doc)
  2. Improve code consistency for not only package itself but also codes using it

What did you see instead?

closed time in 34 minutes

yoseplee

issue commentgolang/go

proposal: crypto/ed25519: change GenerateKey to return private key only

I don't necessarily disagree that it would be cleaner to return just the PrivateKey, but unfortunately the API is now locked in by the Go 1 Compatibility Promise.

https://golang.org/doc/go1compat

yoseplee

comment created time in 34 minutes

Pull request review commentinfluxdata/influxdb

feat(modules): Use modules and go 1.13

+module github.com/influxdata/influxdb++go 1.12++require (

I added them manually and then ran go mod tidy which did away with them. Not sure if it impacted the graph though.

ayang64

comment created time in 3 hours

issue commentgolang/go

x/crypto/ed25519: add montgomery/edwards key conversion

That's the implementation I worked on, which I think is reasonably robust.

We should definitely add examples, but Encode, Decode, FromUniformBytes, ScalarMult, and ScalarBaseMult should be the only APIs you'll need.

SamWhited

comment created time in 19 hours

issue commentgolang/go

x/crypto/ed25519: add montgomery/edwards key conversion

Having public keys with uniform representatives is very useful. If possible could we have this ability in x/crypto as well? Or should I open a separate issue for this?

That's definitely a separate issue, and I would strongly recommend ristretto255 for that use case.

SamWhited

comment created time in 20 hours

pull request commentFiloSottile/captive-browser

doc: remove hard-coded unnecessary parameter

Glad to hear that!

Not sure I understand, to clarify what?

monperrus

comment created time in a day

issue commentgolang/go

cmd/go: non-top-level packages ending in "/vendor" are omitted from module zip files

I suppose we could gate this sort of changes on the go.mod version?

bep

comment created time in a day

issue closedFiloSottile/age

UX: Require verification of keyed password when using -p switch at command line

<!-- Did age not do what you expected? Was it hard to figure out how to do something? Could an error message be more helpful? It's not you, it's us. We want to hear about it. -->

What were you trying to do

Win32 - After entering the password prompt via -p switch, I was not able to verify I entered the correct password as age ran with the first password it was given. There is an opportunity to improve this behavior.

What happened

Age encrypted the file with the password keyed when prompted. Since there was no verification of the keyed password, I have no way of knowing if the password I entered was correct except to try to decrypt the file and test that the password keyed actually was keyed correctly.

<insert terminal transcript here>

closed time in a day

unicorntoes

issue commentFiloSottile/age

UX: Require verification of keyed password when using -p switch at command line

Duplicate of #39 which was fixed but not released. (I really need to make a release!)

unicorntoes

comment created time in a day

PR closed cloudflare/tls-tris

Ed25519 certificates

Ed25519 is specified in the spec https://tools.ietf.org/html/draft-ietf-curdle-pkix-07. TLS 1.3 defines the SignatureScheme for Ed25519.

This requires a patch like https://github.com/golang/go/compare/master...FiloSottile:filippo/ed25519 first, so is not a ready-to-merge PR, just some code I wanted to put out there. Feel free to close the PR or keep it around.

There's also a small bugfix commit you might want to cherry-pick.

+121 -8

1 comment

7 changed files

FiloSottile

pr closed time in 4 days

pull request commentcloudflare/tls-tris

Ed25519 certificates

This functionality is now upstream.

FiloSottile

comment created time in 4 days

issue commentgolang/go

cmd/go: support GOPROXY fallback on unexpected errors

This is not a security no-op, although it might be worth the tradeoff. Is it actually common for proxy.golang.org to fail while sum.golang.org is available?

The difference is that a network adversary becomes capable of causing a fallback to direct. While you're right that this does not impact the privacy of the module names themselves, nor the integrity guarantees of the checksum database, it makes it possible for the code host to observe who is using what. Moreover, list and latest results are not protected by the sumdb, and with this change an attacker would get to hide versions without causing errors by colluding with the host.

It also removes any fallback security provided by the TLS connection to the proxy should the checksum database fail to provide its intended security properties, or should it be disabled. For example, I think we disabled the sumdb in a fetch made by a test, because we are ok with trusting the proxy. If the fallback strategy changes, that would be a very different decision.

heschik

comment created time in 4 days

push eventFiloSottile/filippo.io

Filippo Valsorda

commit sha e6c1a8446b363c3661ee249c542447912ef81f99

Self-host Google fonts

view details

push time in 5 days

push eventFiloSottile/filippo.io

Filippo Valsorda

commit sha 3014b105ca4bc3fa2a351fe7322bd1ce30ca3001

Fix redirects

view details

push time in 5 days

push eventFiloSottile/filippo.io

Filippo Valsorda

commit sha 57995d6688797e5a9a61557675801e045e1be702

Add mta-sts policy

view details

push time in 5 days

pull request commentFiloSottile/captive-browser

doc: remove hard-coded unnecessary parameter

Thank you!

monperrus

comment created time in 5 days

push eventFiloSottile/captive-browser

Martin Monperrus

commit sha 0293a0724b37384faf8f496ee2ccf6a0b5c9f72a

doc: remove unnecessary hardcoded nmcli parameter (#19) nmcli knows how to return the DNS value for a default interface.

view details

push time in 5 days

PR merged FiloSottile/captive-browser

doc: remove hard-coded unnecessary parameter

on some machines, wlp3s0 is not the right one. nmcli knows how to return the DNS value for a default interface.

+1 -1

1 comment

1 changed file

monperrus

pr closed time in 5 days

issue commentFiloSottile/age

Autogenerated passphrase

@graphixillusion Ah, this is golang/go#36609, I updated x/crypto to bring in the fix. Please open a new issue if it's still a problem.

Fastidious

comment created time in 5 days

push eventFiloSottile/age

Filippo Valsorda

commit sha 111d0fe1f4b18e5ac3957dba41949c471957d6e5

go.mod: update x/crypto to bring in fix for golang/go#36609 Updates #78

view details

push time in 5 days

push eventFiloSottile/filippo.io

Filippo Valsorda

commit sha 081718917ace92aa26406f56bf0ac094bf0271ac

Add newsletter link

view details

push time in 6 days

startedmicrocosm-cc/bluemonday

started time in 6 days

push eventFiloSottile/filippo.io

Filippo Valsorda

commit sha 496eed70843e6d8e65f95d1e6be73ea5b19e1f73

Add rel=me and age link

view details

push time in 6 days

issue commentgolang/go

encoding/asn1: accepts non-minimal OID encoding

Let's fix this early so it has time to bake. I'd take a CL for it!

jsha

comment created time in 6 days

issue commentgolang/go

encoding/asn1: accepts non-minimal OID encoding

Do we know of frequent occurrences of this in the wild? (Trying to understand if we'll cause breakage.)

jsha

comment created time in 6 days

issue commentgolang/go

x/crypto/ocsp: Support multiple OCSP responses/requests

Great, I'd appreciate a documentation CL. I personally also find "If the response contains a certificate then the signature over the response is checked." confusing.

paultag

comment created time in 6 days

issue commentgolang/go

x/crypto/ocsp: Support multiple OCSP responses/requests

So this is only needed to parse responses that violate a SHOULD NOT?

paultag

comment created time in 6 days

issue commentgolang/go

proposal: cmd/go: add GOMODCACHE

I suspect that the reason it is not stored within GOPATH/pkg/mod is so that the signed tree head is not removed by go clean -modcache: that way, the signed tree head never regresses. However, I do not know how important that property is to the overall design.

That's correct. It's very important because it's what guarantees that the log is indeed append-only, and it's what lets us worry less about go.sums outside of a module, for example. Every time that's deleted there is a window for the tree to get forked.

I'd prefer it didn't end up in a cache directory. If we are clearing pkg/, maybe UserConfigDir?

mvdan

comment created time in 6 days

issue commentgolang/go

proposal: crypto/tls: Provide access to stapled OCSP response in VerifyPeerCertificate callback

Particularly happy about how easy it makes reproducing (and then customizing) normal verification.

&tls.Config{
	InsecureSkipVerify: true,
	VerifyConnection: func(cs ConnectionState) error {
		opts := x509.VerifyOptions{
			DNSName:       cs.ServerName,
			Intermediates: x509.NewCertPool(),
		}
		for _, cert := range cs.PeerCertificates[1:] {
			opts.Intermediates.AddCert(cert)
		}
		_, err := cs.PeerCertificates[0].Verify(opts)
		return err
	},
}
divjotarora

comment created time in 7 days

issue commentgolang/go

x/crypto/ssh: support RSA SHA-2 host key signatures

How long has OpenSSH supported rsa-sha2-512 certificates?

hansnielsen

comment created time in 7 days

issue commentgolang/go

proposal: crypto/tls: Provide access to stapled OCSP response in VerifyPeerCertificate callback

@katiehockman pointed out that ConnectionState already has all the information needed to verify a peer, and semantically I don't see how we would want things in VerifyPeerCertificate but not in ConnectionState, and vice-versa.

Taking the opportunity to make the semantics of when the callback is invoked more straightforward, we propose this callback.

type Config struct {
	// VerifyConnection, if not nil, is called after normal certificate
	// verification and after VerifyPeerCertificate by either a TLS client
	// or server. If it returns a non-nil error, the handshake is aborted
	// and that error results.
	//
	// If normal verification fails then the handshake will abort before
	// considering this callback. This callback will run for all connections
	// regardless of InsecureSkipVerify or ClientAuth settings.
	VerifyConnection func(ConnectionState) error // Go 1.15

While at it, I propose we set ConnectionState.ServerName on the client side, too. This way VerifyConnection has access to the ServerName that net/http or other intermediate libraries have set dynamically (which is currently a problem when trying to override normal verification from a http.Transport.TLSClientConfig).

An open question is whether we should allow setting both VerifyPeerCertificate and VerifyConnection. It feels cleaner to make them mutually exclusive, but VerifyConnection will run when VerifyPeerCertificate wouldn't if a client certificate is not requested or required, so it's simple but not trivial to implement VerifyConnection in terms of VerifyPeerCertificate.

divjotarora

comment created time in 7 days

issue commentgolang/go

x/crypto/ssh: support RSA SHA-2 host key signatures

Sounds good on both adding the algorithms and changing the certificate default.

OpenSSH 8.2 already stopped supporting ssh-rsa signed certificates, right?

hansnielsen

comment created time in 7 days

issue closedFiloSottile/whoami.filippo.io

Publish SSHFP records

Read more: https://en.wikipedia.org/wiki/SSHFP_record

closed time in 7 days

theel0ja

issue commentFiloSottile/whoami.filippo.io

Publish SSHFP records

filippo.io is DNSSEC signed for an historical accident, and I'm not willing to commit to keeping it signed, sorry.

theel0ja

comment created time in 7 days

issue commentinfluxdata/influxdb

v1.7.10 requires a module by the wrong version

I prepared a cleaned up go.mod with no updates (beyond the ones forced by transitive dependencies) in #16903. I imagine it will not be enough as a PR, so feel free to just take the go.mod from it.

FiloSottile

comment created time in 9 days

PR opened influxdata/influxdb

fix(modules): cleanup go.mod and remove Gopkg.toml
$ rm go.mod
$ go1.14rc1 mod init
go: creating new go.mod: module github.com/influxdata/influxdb
go: copying requirements from Gopkg.lock
go: converting Gopkg.lock: stat github.com/googleapis/gax-go@v2.0.5: github.com/googleapis/gax-go@v2.0.5: invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v2
go: converting Gopkg.lock: stat github.com/google/go-github@dd29b543e14c33e6373773f2c5ea008b29aeac95: github.com/google/go-github@v0.0.0-20181009003523-dd29b543e14c: invalid version: go.mod has post-v0 module path "github.com/google/go-github/v18" at revision dd29b543e14c

Manually added the following lines:
    github.com/googleapis/gax-go/v2 v2.0.5
    github.com/google/go-github/v18 v18.2.1-0.20181009003523-dd29b543e14c

Manually changed the language version:
    go 1.12

$ go1.14rc1 mod tidy
go: gopkg.in/russross/blackfriday.v2@v2.0.1/go.mod: verifying module: gopkg.in/russross/blackfriday.v2@v2.0.1/go.mod: reading https://sum.golang.org/lookup/gopkg.in/russross/blackfriday.v2@v2.0.1: 410 Gone
	server response: not found: gopkg.in/russross/blackfriday.v2@v2.0.1: invalid version: go.mod has non-....v2 module path "github.com/russross/blackfriday/v2" at revision v2.0.1

Manually fixed the blackfriday module path:
    github.com/russross/blackfriday/v2 v2.0.1

$ go1.14rc1 mod tidy
$ git rm Gopkg.lock Gopkg.toml

Closes #16901

+35 -1502

0 comment

3 changed files

pr created time in 9 days

push eventFiloSottile/influxdb

Filippo Valsorda

commit sha 2f1a9efafc5d683434c2ec7370a6d56e289fef42

fix(modules): cleanup go.mod $ rm go.mod $ go1.14rc1 mod init go: creating new go.mod: module github.com/influxdata/influxdb go: copying requirements from Gopkg.lock go: converting Gopkg.lock: stat github.com/googleapis/gax-go@v2.0.5: github.com/googleapis/gax-go@v2.0.5: invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v2 go: converting Gopkg.lock: stat github.com/google/go-github@dd29b543e14c33e6373773f2c5ea008b29aeac95: github.com/google/go-github@v0.0.0-20181009003523-dd29b543e14c: invalid version: go.mod has post-v0 module path "github.com/google/go-github/v18" at revision dd29b543e14c Manually added the following lines: github.com/googleapis/gax-go/v2 v2.0.5 github.com/google/go-github/v18 v18.2.1-0.20181009003523-dd29b543e14c Manually changed the language version: go 1.12 $ go1.14rc1 mod tidy go: gopkg.in/russross/blackfriday.v2@v2.0.1/go.mod: verifying module: gopkg.in/russross/blackfriday.v2@v2.0.1/go.mod: reading https://sum.golang.org/lookup/gopkg.in/russross/blackfriday.v2@v2.0.1: 410 Gone server response: not found: gopkg.in/russross/blackfriday.v2@v2.0.1: invalid version: go.mod has non-....v2 module path "github.com/russross/blackfriday/v2" at revision v2.0.1 Manually fixed the blackfriday module path: github.com/russross/blackfriday/v2 v2.0.1 $ go1.14rc1 mod tidy $ git rm Gopkg.lock Gopkg.toml Fixes #16901

view details

push time in 9 days

fork FiloSottile/influxdb

Scalable datastore for metrics, events, and real-time analytics

https://influxdata.com

fork in 9 days

issue commentinfluxdata/influxdb

v1.7.10 requires a module by the wrong version

Looks like the go.mod was created with go mod init which printed errors about those v2 modules, but they were not fixed.

The reason it looks like it's updating stuff when you run it is that go mod tidy will report in your go.mod the version that's actually being used based on the dependency graph.

For example, you require github.com/cespare/xxhash@v1.0.0, but also github.com/influxdata/flux@v0.50.2 which requires github.com/cespare/xxhash@v1.1.0, so go mod tidy just reports it correctly.

$ go mod graph
github.com/influxdata/influxdb github.com/influxdata/flux@v0.50.2
github.com/influxdata/flux@v0.50.2 github.com/cespare/xxhash@v1.1.0
FiloSottile

comment created time in 9 days

push eventFiloSottile/whoami.filippo.io

Filippo Valsorda

commit sha 3a10fbf16f9e55a9be754b83991c27795bf23b1d

Add metrics

view details

push time in 10 days

issue openedinfluxdata/influxdb

v1.7.10 requires a module by the wrong version

github.com/influxdata/influxdb@v1.7.10 requires github.com/google/go-github@v0.0.0-20181009003523-dd29b543e14c. Commit google/go-github@dd29b543e14c shows a go.mod with path github.com/google/go-github/v18 so it can't be used with v0.0.0 and naked github.com/google/go-github import path.

Go 1.13 notices and breaks.

go: github.com/influxdata/influxdb@v1.7.10 requires
	github.com/google/go-github@v0.0.0-20181009003523-dd29b543e14c: invalid version: go.mod has post-v0 module path "github.com/google/go-github/v18" at revision dd29b543e14c

In other words, github.com/google/go-github@v0.0.0-20181009003523-dd29b543e14c doesn't exist, that commit is github.com/google/go-github/v18@v18.2.1-0.20181009003523-dd29b543e14c.

created time in 10 days

PR closed FiloSottile/whoami.filippo.io

Add /etc/ssh_config to the list of possible config locations

I noticed that, on OSX (at least on 10.10.5), the ssh config is not stored in either of the suggested locations (~/.ssh/config or /etc/ssh/ssh_config) but rather /etc/ssh_config. I simply added the third option to the output string.

+3 -2

1 comment

1 changed file

CrshOverride

pr closed time in 10 days

pull request commentFiloSottile/whoami.filippo.io

Add /etc/ssh_config to the list of possible config locations

On modern macOS users are not supposed to edit /etc, so ~/.ssh/config is the right path for them.

CrshOverride

comment created time in 10 days

PR closed FiloSottile/whoami.filippo.io

Accurately reflect key-sending reality

Fixes #9 Accurately reflect key-sending reality

+10 -6

1 comment

1 changed file

jblaine

pr closed time in 10 days

pull request commentFiloSottile/whoami.filippo.io

Accurately reflect key-sending reality

https://github.com/FiloSottile/whoami.filippo.io/issues/9#issuecomment-586660092

jblaine

comment created time in 10 days

issue closedFiloSottile/whoami.filippo.io

SSH does not send all public keys

2 public keys.

1 sent.

[@dev:~] $ ssh -V
OpenSSH_6.6.1p1, OpenSSL 1.0.1e-fips 11 Feb 2013
[@dev:~] $ cat /etc/redhat-release
CentOS Linux release 7.1.1503 (Core)
[@dev:~] $ ls -ld .ssh/id_rsa*pub
-rw-r--r--. 1 jblaine jblaine 393 Jun 19 10:34 .ssh/id_rsa.pub
-rw-r--r--. 1 jblaine jblaine 393 Aug  6 12:12 .ssh/id_rsa_another.pub
[@dev:~] $ ssh whoami.filippo.io

    +---------------------------------------------------------------------+
    |                                                                     |
    |             _o/ Hello!                                              |
    |                                                                     |
    |                                                                     |
    |  Did you know that ssh sends all your public keys to any server     |
    |  it tries to authenticate to? You can see yours echoed below.       |
    |                                                                     |
    |  We tried to use that to find your GitHub username, but we          |
    |  couldn't :( maybe you don't even have GitHub ssh keys, do you?     |
    |                                                                     |
    |  By the way, did you know that GitHub publishes all users'          |
    |  ssh public keys and Ben (benjojo.co.uk) grabbed them all?          |
    |                                                                     |
    |  That's pretty handy at times :) But not this time :(               |
    |                                                                     |
    |                                                                     |
    |  P.S. This whole thingy is Open Source! (And written in Go!)        |
    |  https://github.com/FiloSottile/whosthere                           |
    |                                                                     |
    |  -- @FiloSottile (https://twitter.com/FiloSottile)                  |
    |                                                                     |
    +---------------------------------------------------------------------+

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDQwpvEpjvC+wCs41YLSxxr4Fre9Gtk4aWhoVkGWN10CQSTV3RVfDzmDsusTul0XrcetmlCQBEwfImxly1cFp/pcjTT0lAlmwuY6a8vxqCZ1D83IT8suYQIONu7dzV5PrVK1e0h02v0hGxrgGgpG1eXmD3LgCUkQHNzyQip60DmkjW6nC6lspCeJ/nghh7ioHScJfjIyMBIXI5NqumuLfnUQ7sN7fJXpsgzE5IusMikdnsOdN6qhSSjuXRAYAOyBtAv62qBQ0vYlIWFKL4iWwJG4fqXZNjBh8YpIXnLwPFD0oKmGRzRxBVPIw39qgMXJDYkjTCDmk0iclc787OIbS4N

Connection to whoami.filippo.io closed.
[@dev:~] 1 $ ls .ssh/config
ls: cannot access .ssh/config: No such file or directory
[@dev:~] 2 $

closed time in 10 days

jblaine

issue commentFiloSottile/whoami.filippo.io

SSH does not send all public keys

Most users only have default and agent keys, so for them it's all keys. Advanced users that have different keys already know the configs, so we can keep it simple.

jblaine

comment created time in 10 days

push eventFiloSottile/whoami.filippo.io

Filippo Valsorda

commit sha e6137d463d44c2ab10e7520cf0058b465a5af302

Add key fingerprints to README Fixes #22

view details

push time in 10 days

issue closedFiloSottile/whoami.filippo.io

Provide SSH host key fingerprint(s) in the README

Thousands of people answered "yes" to

<pre> The authenticity of host 'whoami.filippo.io (96.246.192.163)' can't be established. RSA key fingerprint is SHA256:O6zDQjQws92wQSA41wXusKquKMuugPVM/oBZXNmfyvI. Are you sure you want to continue connecting (yes/no)? <strong>no</strong> </pre>

when first connecting to your server.

Here's a chance to perform another valuable public service—on top of encouraging good public key hygiene—by subtly reminding people in whosthere's README that they shouldn't ignore these warnings, but rather actually verify the fingerprints with the server administrator.

For example, GitHub puts their host key fingerprints on their website, and every upstanding company in the business of providing services over SSH hosting should do the same.

We wouldn't create permanent exceptions for broken SSL/TLS certificates on our banks' web sites, would we? Super! Browsers have scary warnings about certificate errors for the same reasons that SSH clients have scary warnings about host fingerprints. It's kind of a big deal.

closed time in 10 days

ernstki

push eventFiloSottile/whoami.filippo.io

Filippo Valsorda

commit sha 467c5494c093e79a29d441500c7b0dc5032311a9

Quote all the things

view details

push time in 10 days

issue openedgolang/go

x/crypto/ssh: add support for hostkeys@openssh.com

The hostkeys@openssh.com extension lets a server notify a client of all its host keys to enable a smooth transition if they have UpdateHostKeys enabled. We should offer it server-side.

created time in 10 days

push eventFiloSottile/whosthere

Filippo Valsorda

commit sha f8a1824afb06decdb3caa42ee8cbaadedc90915f

Update all dependencies and module path

view details

Filippo Valsorda

commit sha 35ab6b76750e8b1ad700c8aa34f52ba2787d97b4

Add support for new refreshed database and Ed25519 host key Fixes #3

view details

push time in 10 days

issue closedFiloSottile/whosthere

Doesn't work with my ed25519 key

I tried it but it doesn't work with my ed25519 key. Here's the output:

$ ssh whoami.filippo.io  

    +---------------------------------------------------------------------+
    |                                                                     |
    |             _o/ Hello!                                              |
    |                                                                     |
    |                                                                     |
    |  Did you know that ssh sends all your public keys to any server     |
    |  it tries to authenticate to? You can see yours echoed below.       |
    |                                                                     |
    |  We tried to use that to find your GitHub username, but we          |
    |  couldn't :( maybe you don't even have GitHub ssh keys, do you?     |
    |                                                                     |
    |  By the way, did you know that GitHub publishes all users'          |
    |  ssh public keys and Ben (benjojo.co.uk) grabbed them all?          |
    |                                                                     |
    |  That's pretty handy at times :) But not this time :(               |
    |                                                                     |
    |                                                                     |
    |  P.S. This whole thingy is Open Source! (And written in Go!)        |
    |  https://github.com/FiloSottile/whosthere                           |
    |                                                                     |
    |  -- @FiloSottile (https://twitter.com/FiloSottile)                  |
    |                                                                     |
    +---------------------------------------------------------------------+


Connection to whoami.filippo.io closed.

as you can see, my key is not echoed below as claimed in the text.

I checked the ssh -v output and I'm definitely offering the key:

$ ssh -i ~/.ssh/id_ed25519 -v whoami.filippo.io  
OpenSSH_6.9p1, OpenSSL 1.0.1m 19 Mar 2015
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to whoami.filippo.io [178.32.139.168] port 22.
debug1: Connection established.
debug1: identity file /home/philandstuff/.ssh/id_ed25519 type 4
debug1: key_load_public: No such file or directory
debug1: identity file /home/philandstuff/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.9
debug1: Remote protocol version 2.0, remote software version Go
debug1: no match: Go
debug1: Authenticating to whoami.filippo.io:22 as 'philandstuff'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-sha2-256 none
debug1: kex: client->server aes128-ctr hmac-sha2-256 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ssh-rsa SHA256:O6zDQjQws92wQSA41wXusKquKMuugPVM/oBZXNmfyvI
debug1: Host 'whoami.filippo.io' is known and matches the RSA host key.
debug1: Found key in /home/philandstuff/.ssh/known_hosts:5
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering ED25519 public key: /home/philandstuff/.ssh/id_ed25519
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug1: Authentication succeeded (keyboard-interactive).
Authenticated to whoami.filippo.io ([178.32.139.168]:22).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.

    +---------------------------------------------------------------------+
    |                                                                     |
    |             _o/ Hello!                                              |
    |                                                                     |
    |                                                                     |
    |  Did you know that ssh sends all your public keys to any server     |
    |  it tries to authenticate to? You can see yours echoed below.       |
    |                                                                     |
    |  We tried to use that to find your GitHub username, but we          |
    |  couldn't :( maybe you don't even have GitHub ssh keys, do you?     |
    |                                                                     |
    |  By the way, did you know that GitHub publishes all users'          |
    |  ssh public keys and Ben (benjojo.co.uk) grabbed them all?          |
    |                                                                     |
    |  That's pretty handy at times :) But not this time :(               |
    |                                                                     |
    |                                                                     |
    |  P.S. This whole thingy is Open Source! (And written in Go!)        |
    |  https://github.com/FiloSottile/whosthere                           |
    |                                                                     |
    |  -- @FiloSottile (https://twitter.com/FiloSottile)                  |
    |                                                                     |
    +---------------------------------------------------------------------+


debug1: channel 0: free: client-session, nchannels 1
Connection to whoami.filippo.io closed.
Transferred: sent 2832, received 3136 bytes, in 0.1 seconds
Bytes per second: sent 43503.6, received 48173.5
debug1: Exit status -1

closed time in 10 days

philandstuff

PR closed FiloSottile/whosthere

Added a section on config.yml

With respect to #5 I sketched out what config.yml and the MySQL database should look like.

+34 -1

1 comment

1 changed file

greymeister

pr closed time in 10 days

pull request commentFiloSottile/whosthere

Added a section on config.yml

As in #5, this is not meant to be easy to reuse, but doesn't use a config file anymore.

greymeister

comment created time in 10 days

issue closedFiloSottile/whosthere

Complete the README

Could you explain in the README how to install and run ssherver for Go newbe and show an example of config.yml ?

closed time in 10 days

Oros42

issue commentFiloSottile/whosthere

Complete the README

This is not really meant to be easy to run yourself, but it's now entirely environment variable based, so there is no config.yml.

Oros42

comment created time in 10 days

issue closedFiloSottile/whosthere

not enough arguments in call to s.githubClient.Users.Get

ssh://whoami.filippo.io is down, so I'm trying to build this myself, but I got the following compile error:

 ~ > go get github.com/FiloSottile/whosthere/src/ssherver                                                                                                      
# github.com/FiloSottile/whosthere/src/ssherver                                 
go/src/github.com/FiloSottile/whosthere/src/ssherver/db.go:30: not enough arguments in call to s.githubClient.Users.Get
        have (string)                   
        want (context.Context, string)  
 ✘ ~ > 

I apologize if this is just go noobery but it seems like a normal compile error so I decided that's unlikely.

closed time in 10 days

virtualdxs

issue commentFiloSottile/whosthere

not enough arguments in call to s.githubClient.Users.Get

Thanks for the report. This was fixed a while ago, and we now use modules so API breakages won't affect us anymore.

virtualdxs

comment created time in 10 days

issue commentgolang/go

cmd/go: global go get does not reference main package's module's go.sum

For what it's worth, there is a degree of per-machine reproducibility because the tree head of the checksum database which is stored in $GOPATH/pkg/sumdb/sum.golang.org/latest can only ratchet forward on a certain machine, and it can't include disagreeing values for the same module version without detection by auditors.

“Module mode outside of a main module” can't get any better than that I suspect, because there is no way to verify the go.sum of the go geted module itself, so relying on it would be fairly moot.

myitcv

comment created time in 11 days

issue commentgolang/go

proposal: crypto/x509: add API to create RFC-compliant CRLs

One thing I'd suggest against is including Version, as far as I know there is no real call for creating anything other than X509v2 CRLs. I believe the field in Certificate only exists for parsing, as CreateCertificate only creates X509v3 certs. I think it's probably best to leave it out and then if a parsing method is added down the line to include it then in order to avoid confusion.

Agreed, we can introduce it along with a parsing function if needed.

jefferai

comment created time in 13 days

issue commentgolang/go

proposal: crypto/tls: add GetConfigForServer callback to *tls.Config

This comes up fairly often, so we have an example for it in Go 1.14.

https://tip.golang.org/pkg/crypto/tls/#example_Config_verifyPeerCertificate

nhooyr

comment created time in 13 days

issue closedgolang/go

wiki: clarify Assembly Policy for crypto

Current Assembly Policy establish general guidelines for inclusion of assembly implementations. However there is some confusion about it application to crypto. I think we should clarify the following questions:

  • Are assembly implementations of new (to go) modes/hashes/block-ciphers allowed at all?
  • If they are allowed, we should have a list of deprecated stuff, that is intended to be slow e. g. rc4.
  • Are there any additional requirements for testing crypto asm?
  • Can I (or anyone without great background in crypto) +2 straightforward cases e. g. https://go-review.googlesource.com/c/go/+/125316 ?
  • If we are not going to accept new assembly implemntaions, than we must do something with CLs sent before creation of assembly policy, that are still in review, e. g. https://go-review.googlesource.com/c/go/+/109135

closed time in 13 days

TocarIP

issue commentgolang/go

wiki: clarify Assembly Policy for crypto

Folding into #37168. These are all good questions that I'd like us to provide clear answers for (except maybe an explicit performance ration at which we bring in assembly, because I think it will always be a judgement call based on a number of hard to capture factors).

TocarIP

comment created time in 13 days

issue commentgolang/go

proposal: new cryptographic assembly policy

In general the policy seems good to me, though I do feel that if a contributor is following the current assembly policy then they would already be meeting the bar of the new one. Maybe we need to expand the advice even more, I'm not sure.

Hmm, the major differences should be a stronger preference for code generation, and the requirement for a Go reference implementation that matches small assembly functions 1:1. For example, there are generic implementations that do 32-bit limbs while the assembly does 64-bit limbs, and that would not be acceptable anymore, or assembly where the only entry point is ScalarMult, which would have to be broken up in a dozen or so functions.

One thing that this proposal doesn't address is the fairly common practice of taking assembly from another project (e.g. OpenSSL) and porting it to Go assembly. I see this in reviews every so often. One concrete thing that I think we should encourage people to do is to document the repositories and, importantly, the exact version control revisions that their code is based on so that it is easier to check for upstream changes. Having said that, when reviewing such code do you think that it is better to encourage keeping the code close to the original so that it is easier to update with upstream changes (assuming anyone ever bothers to check for them) or to modify it more heavily to fit with the policy? Sometimes contributors don't fully understand the implementation or algorithm they are porting and so it will be very hard for them to rework it to fit with the policy. Or they may just be reluctant to change the code too much. How firm should we be in that sort of situation, assuming it is otherwise well tested?

I should mention that by default, this is not ok license-wise. There's a path to bring in assembly that was dual-licensed as part of cryptogams, and that's what was taken a couple times.

I think we tried the "keep the port close to the source" route, and it does not meet the standards of maintainability we'd like to have, also because the source is often in perlasm or something like that, and the calling conventions are different, and Go has reserved registers, etc.

I'd like us to try developing a small and curated set of assembly implementations rather than bring in large amounts from other projects with different priorities.

One other point I'd like to make is that I don't think we should mandate the use of code generation. It should only be used when it would increase maintainability. Short hand-written assembly files can be preferable in some situations.

This is particularly experimental, and I'm willing to reconsider after we've seen some results, but I'd like to try it out, as I think it might lead to much better readability and portability. Maybe it will even force the creation of more tools like avo that can abstract some of the useless manual work.

FiloSottile

comment created time in 13 days

issue commentgolang/go

proposal: crypto/tls: add GetConfigForServer callback to *tls.Config

The only use case otherwise seems to be rotating RootCAs, which I think is narrow enough to be worth solving with a custom VerifyPeerCertificate.

Fair enough, it'd just be unfortunate if in the future there was another use case where dynamically adjusting another field on the *tls.Config made sense as then we'd have to add another mechanism.

I'd be happy to discuss again in a new proposal if another use case comes up, as it would be easier to evaluate the design then.

nhooyr

comment created time in 14 days

startedgliderlabs/ssh

started time in 14 days

issue commentgolang/go

proposal: crypto/tls: implement Session IDs resumption

This is terrifying: it looks like there are FTP servers that use session reuse as an authentication method across control and data connections, and some of them don't support session tickets, so need session IDs. https://github.com/secsy/goftp/issues/49

https://scarybeastsecurity.blogspot.com/2009/02/vsftpd-210-released.html

pvoicu

comment created time in 14 days

issue commentgolang/go

proposal: crypto/tls: add GetConfigForServer callback to *tls.Config

For certificate rotation GetClientCertificate should work, or am I misunderstanding?

The only use case otherwise seems to be rotating RootCAs, which I think is narrow enough to be worth solving with a custom VerifyPeerCertificate.

nhooyr

comment created time in 14 days

issue commentgolang/go

x/crypto/acme/autocert: Enable custom port / IP binding

@x1ddos, does https://github.com/golang/go/issues/29540#issuecomment-458711482 look good to you?

axxelG

comment created time in 14 days

issue closedgolang/go

proposal: concrete interfaces for crypto.PublicKey and crypto.PrivateKey

Currently crypto.PublicKey and crypto.PrivateKey are empty interfaces.

This has bitten me a number of times because errors that could easily be caught by tooling or at compile time become runtime errors (sometimes very confusing ones).

It appears that all Private Keys in the crypto package include PublicKey or Public() crypto.PublicKey. I assume that, by their very nature, any future invention of asymmetric keys will include the Public Key as part of the definition of the Private Key.

There's also a well-known and intuitive standard way to compute a key Thumbprint that would work on any existing asymmetric keys and any future asymmetric keys. I believe there are also one or more well-known ways to compute a Fingerprint (SSH, among others), but perhaps Thumbprint is more distinct in that there is only one such specification (as far as I know).

I propose that crypto.PrivateKey be changed as follows:

type PrivateKey {
    Public() crypto.PublicKey
}

And that crypto.PublicKey likewise change to something like this:

type PublicKey {
    ThumbprintSHA256() []byte
}

closed time in 14 days

solderjs

issue commentgolang/go

proposal: concrete interfaces for crypto.PublicKey and crypto.PrivateKey

#21704 is likely to be accepted, and it proposed adding Equal(crypto.PublicKey) bool to all PublicKeys, so that would be the way to identify public keys.

For private keys, we already have Public() crypto.PublicKey, so I think this got resolved.

Closing as duplicate of #21704.

solderjs

comment created time in 14 days

issue commentgolang/go

proposal: crypto/tls: Provide access to stapled OCSP response in VerifyPeerCertificate callback

I'm afraid you are correct. I can only think of two solutions, both not great: adding a new callback, or adding a global map accessible via something like tls.PeerCertificatesAdditionalData(rawCerts [][]byte) *SomeStruct which gets populated right before any call to VerifyPeerCertificate and cleaned up immediately after the callback returns.

divjotarora

comment created time in 14 days

issue commentgolang/go

proposal: x/crypto/ssh: add methods to marshal private keys to the OpenSSH format

Looks good to me. Returning a *pem.Block seems like a good compromise between returning PEM encoded []byte, which is weird, and being consistent with the parsing function, which takes PEM.

maraino

comment created time in 14 days

issue commentgolang/go

proposal: crypto/x509: add API to create RFC-compliant CRLs

I like the symmetry with Certificate and CertificateRequest and the option to add a parser later. CertificateRevocationList is a mouthful though. Just like we shortened CSR to CertificateRequest, how about shortening CRL to RevocationList?

Here's a suggested API. Note the following changes:

  • CreateRevocationList and RevocationList names
  • order of arguments to CreateRevocationList matching CreateCertificate
  • order of fields resembling Certificate and CertificateRequest
  • *big.Int for Number because it can be up to 20 bytes
  • ExtraExtensions instead of Extensions like Certificate and CertificateRequest (which I'm not a fan of, but we might as well keep it all consistent)
func CreateRevocationList(rand io.Reader, template *RevocationList,
	issuer *x509.Certificate, priv crypto.Signer) ([]byte, error)

type RevocationList struct {
	Version            int
	SignatureAlgorithm SignatureAlgorithm

	RevokedCertificates []pkix.RevokedCertificate

	Number          *big.Int
	ThisUpdate      time.Time
	NextUpdate      time.Time
	ExtraExtensions []pkix.Extension
}
jefferai

comment created time in 14 days

issue commentgolang/go

proposal: crypto/x509: parse additional fields in CertificateRequest

Sounds good, we should even be able to share code with the Certificate parser.

chauncyc

comment created time in 14 days

issue commentgolang/go

proposal: new cryptographic assembly policy

/cc a number of crypto assembly implementers: @mundaym @laboger @mengzhuo @ceseo @crvv @TocarIP @aead @vkrasnov @ncw @gtank @bmakam-qdt

FiloSottile

comment created time in 14 days

issue openedgolang/go

proposal: new cryptographic assembly policy

The crypto packages are unfortunately rich in assembly implementations, which are especially hard to review and maintain due to the diversity of architectures, and to the complexity of the optimizations.

Our current assembly policy at golang.org/wiki/AssemblyPolicy has failed to make reviews manageable with the resources the security team currently has. https://go-review.googlesource.com/q/hashtag:crypto-assembly

The result is suboptimal for everyone: implementers have to follow more rules, but reviewers still can’t effectively review their CLs, and no one is happy.

I am proposing a new, much stricter policy. This acknowledges the reality that assembly reviews are currently not moving at an acceptable pace, and shifts more of the load on the implementers, but with a promise that their work won’t go wasted in the review queue. It should also progressively increase the maintainability, reliability and security of the assembly codebases, as well as surface improvement areas for the compiler so that the assembly can be eventually removed.

This policy would apply to all packages in crypto/... and golang.org/x/crypto/.... Due to its use in cryptographic packages, and to the fact that it's partially maintained by the security team, this policy would also extend to math/big.


  • We prefer portable Go, not assembly. Code in assembly means (N packages * M architectures) to maintain, rather than just N packages.
  • Minimize use of assembly. We'd rather have a small amount of assembly for a 50% speedup rather than twice as much assembly for a 55% speedup. Explain the decision to place the assembly/Go boundary where it is in the commit message, and support it with benchmarks.
  • Use higher level programs to generate assembly, either standalone Go programs or go get-able programs, like avo. Output of other reproducible processes (like formally verified code generators) will also be considered. Discuss the implementation strategy on the issue tracker in advance.
  • Use small, testable units (25–75 lines) called from higher-level logic written in Go. If using small, testable units called from logic written in Go is too slow, use small, testable assembly functions with Go-compatible wrappers, so that Go tests can still test the individual units.
  • Any assembly function needs a reference Go implementation, that’s tested and fuzzed side-by-side with the assembly. Follow golang.org/wiki/TargetSpecific for structure and testing practices.
  • Document in the Go code why the implementation requires assembly (specific performance benefit, access to instructions, etc), so we can reevaluate as the compiler improves.

created time in 14 days

startedtailscale/tailscale

started time in 15 days

starteddmtx/libdmtx

started time in 17 days

startedintra2net/paperbackup

started time in 18 days

issue commentgolang/go

dev.boringcrypto branch behind the main releases (1.13.4b4 vs 1.13.6)

Sorry for the delay!

sodul

comment created time in 18 days

issue commentgolang/go

x/crypto: release-branch.go1.12 was removed

@wgja I believe that was 56440b844dfe139a8ac053f4ecac0b20b79058f4.

We need branches to make cherry-picks on them if we need to change the code vendored in old Go releases, but again, these are not things anyone externally should rely on.

danws2020

comment created time in 18 days

pull request commentgolang/crypto

chacha20: add Advance method

FYI folks, we do not monitor comments on GitHub PRs.

Please don’t reply on this GitHub thread. Visit golang.org/cl/206638.

Please open an issue about this, and then feel free to send a CL fixing it.

lukechampine

comment created time in 18 days

issue commentgolang/go

x/crypto/chacha20: add Cipher.SetCounter

Yeah, fair, naming things is hard. Let's just go back to SetCounter. The docs can explain the rollback behavior.

FiloSottile

comment created time in 18 days

startedapenwarr/git-subtrac

started time in 19 days

issue commentgolang/go

x/crypto: release-branch.go1.12 was removed

@wgja My apologies for the confusion and the breakage. To clarify, release-branch.go1.11 does NOT mean "the code that's compatible with Go 1.11", but "the code that ships in the vendor folder of Go 1.11". You should treat x/crypto like you treat any other module, and pin the latest commit that works for you. As long as a Go release is maintained, it will work with x/crypto master. Go 1.11 is unmaintained so you might indeed have to pin an old commit.

danws2020

comment created time in 19 days

issue commentgolang/go

crypto/ecdsa: make PublicKey implement encoding.TextMarshaler/TextUnmarshaler using PEM

If this works out we might consider extending it to other PublicKey and maybe PrivateKey types, but I'm afraid we'll run into import loops with crypto/x509, where the encoding functions are.

nulldowntime

comment created time in 20 days

issue commentgolang/go

proposal: crypto/x509: expose hash algorithm for SignatureAlgorithm

What are we supposed to return for Ed25519? What does channel binding end up using with it?

bodgit

comment created time in 20 days

issue commentgolang/go

dev.boringcrypto: update BoringCrypto module

I'll give this a shot for Go 1.14 then.

akashgiri

comment created time in 20 days

issue commentgolang/go

proposal: crypto/elliptic: automatically upgrade CurveParams for known curves and deprecate custom ones

Flagging as a proposal to discuss deprecating the generic, not constant time methods Add, Double, IsOnCurve, ScalarBaseMult and ScalarMult of CurveParams. Everyone should be instead using the methods on a named curve like P256().

FiloSottile

comment created time in 20 days

issue closedgolang/go

proposal: crypto/tls: add function to dynamically load more than one certificate for a multi-domain server

Hello,

Please add a function to load dynamically more than one certificate for multi domain server.

tlsConfig := &tls.Config{
	PreferServerCipherSuites: true,
	MinVersion:               tls.VersionTLS13,
	ClientCAs:                caCertPool,
	GetClientCertificates:     certR.GetCertificatesFunc(), // more than one
	//ClientAuth: tls.RequireAndVerifyClientCert,
}


func (cr *certReloader) GetCertificatesFunc() func(*tls.ClientHelloInfo) ([]*tls.Certificate, error) {
	return func(chi *tls.ClientHelloInfo) ([]*tls.Certificate, error) {
		cr.m.RLock()
		defer cr.m.RUnlock()
		return cr.certs, nil
	}
}

closed time in 20 days

mvasi90

issue commentgolang/go

proposal: crypto/tls: add function to dynamically load more than one certificate for a multi-domain server

You can use Config.GetConfigForClient, and set the Certificates field in the returned Config.

mvasi90

comment created time in 20 days

issue commentgolang/go

proposal: crypto/tls: Export list of Supported TLS Client Extensions

We don't surface values to the application when there is no other use case than fingerprinting. Not because fingerprinting is not a valid use case, but because it asymptotically tends to require access to everything, polluting the API.

Instead, I usually recommend making a net.Conn wrapper that reads the ClientHello off the wire and makes all of the details available as needed.

fishboy25uk

comment created time in 20 days

issue commentgolang/go

proposal: crypto: update dev.boringcrypto branches as per security policies

@agl Can we / should we update the reference to 140sp3318.pdf? AFAIK we have not updated the BoringCrypto module itself. (Should we do that when a new validation comes through?)

akashgiri

comment created time in 20 days

issue commentgolang/go

x/tools/cmd/godoc: Certificate.Leaf anchor is incorrect

Hah, it's because there's a documentation line that starts with Leaf in the PrivateKey docs.

This is an x/tools/cmd/godoc bug.

/cc @dmitshur

c-yan

comment created time in 20 days

issue commentgolang/go

proposal: crypto/tls: Authority Information Access support

(Hah, I didn't know we already parse the AIA extension into Certificate.IssuingCertificateURL. Much easier then! By the way I'd recommend using net.SplitHostPort in of tlsHost.)

ConradIrwin

comment created time in 21 days

issue commentgolang/go

proposal: crypto/tls: Authority Information Access support

Thanks for the detailed reply. I understand the principle of reducing the attack surface here.

It's certainly not very common to see AIA on the internet (as evidenced by the fact that most images load just fine), but it's common enough that we've had multiple independent reports of this not working. Do you know how common it would have to be for this to ship with go?

(I'm assuming that some things are included (despite being bad ideas) because they're necessary for interoperability, and can probably get some numbers on the % of domains we see with this feature enabled (if Google doesn't already have that in an internal dashboard somewhere :D)).

I don't have an explicit bar to commit to, also because it moves depending on the complexity and attack surface cost, as well as an ecosystem benefit rationale. For AIA, the bar would be very high, also because I believe it's good for the ecosystem to leave AIA behind, rather than adopt it further.

Also, I'd love your help with a little more direction on "write a thrid-party module that parses AIA with golang.org/x/crypto/cryptobyte, fetches the intermediate, and repeats a failed validation with it in the pool."

Would this require a replacement to crypto/x509 and implementing an http.RoundTripper that uses that, or are there hooks I could use to add this functionality to the existing network stack?

This would be logic in your custom tls.Config.VerifyPeerCertificate, which you can set in http.Transport.TLSClientConfig.

If the verification fails, you'd look at certs[0].Extensions, find the one with the AIA OID, parse its value with golang.org/x/crypto/cryptobyte, add the CA to the x509.VerifyOptions.Intermediates pool, and try Verify again.

ConradIrwin

comment created time in 21 days

issue commentsecure-systems-lab/ssl-site

Transparent Logs and TUF: clarify compromise recovery

The difference is that TUF will switch users from the old to the new root keys permanently (which can be done safely provided that attackers no longer control the repository, and the repository is also using TLS).

I think I'm still missing the semantic difference (that is, beyond where and how the keys are stored). The online keys in TUF are the tree signing keys in the sumdb, the root keys in TUF are the release signing keys in Go, all keys rotate permanently upon update (the signatures by the old untrusted key would be just ignored by updated clients), and if you have a TLS connection to an entity you trust you can pull it off securely.

trishankatdatadog

comment created time in 21 days

issue openedgolang/go

dev.boringcrypto: switch Docker images to Debian Buster

Debian Stretch will reach EOL this year. By then we should switch the Go+BoringCrypto Docker images to be based on Buster. The golang docker images default to Buster already.

Not really sure how to announce this change, as there is no Go+BoringCrypto release notes.

created time in 21 days

more