4 ms·

> meet the goals of usability If server blacklists your TLS fingerprint, you can no longer use that server with that client. Only workaround would be a client

> meet the goals of usability If server blacklists your TLS fingerprint, you can no longer use that server with that client. Only workaround would be a client that can configure its own fingerprint. What you're saying is akin to "let remove the clients ability to set HTTP headers". IE its just nonsense. If server rejects every request because of clients TLS configuration, and client has no agency over that configuration, then the client has no usability. > Note that nowhere was there a hard no, we'll never implement this I would say the maintainer closing the issue, is a pretty clear signal for that: https://github.com/golang/go/issues/48207#event-7373771032 https://github.com/golang/go/issues/48207#event-7373771032

mirashii 4y ago
The issue was closed for bypassing fingerprinting, a use case that the maintainers feel is not a valid precursor to this feature. Again, that isn’t a no to the feature under any circumstance, just a statement that this use case is insufficient. More generally, if a server wants to fingerprint you, there are a variety of additional fields and changes that will flow from that as it’s an arms race, one that this libraries authors are not inclined to keep adding features and configuration for them. There exist other libraries for this purpose, some linked in the discussion. So no, it’s not like saying you can’t set your own HTTP headers at all, more akin to saying that if your needs fall outside the 99% use case you may need to go elsewhere.
- svnpenn 4y ago
  > The issue was closed for bypassing fingerprinting, a use case that the maintainers feel is not a valid precursor to this feature. Again, that isn’t a no to the feature under any circumstance, just a statement that this use case is insufficient. I implore you to open a new issue then, under the guise of your valid use case. I am sure that it will stay open, and that it will not be closed as a duplicate /s

mirashii 4y ago

The issue was closed for bypassing fingerprinting, a use case that the maintainers feel is not a valid precursor to this feature. Again, that isn’t a no to the feature under any circumstance, just a statement that this use case is insufficient. More generally, if a server wants to fingerprint you, there are a variety of additional fields and changes that will flow from that as it’s an arms race, one that this libraries authors are not inclined to keep adding features and configuration for them. There exist other libraries for this purpose, some linked in the discussion. So no, it’s not like saying you can’t set your own HTTP headers at all, more akin to saying that if your needs fall outside the 99% use case you may need to go elsewhere.

svnpenn 4y ago
> The issue was closed for bypassing fingerprinting, a use case that the maintainers feel is not a valid precursor to this feature. Again, that isn’t a no to the feature under any circumstance, just a statement that this use case is insufficient. I implore you to open a new issue then, under the guise of your valid use case. I am sure that it will stay open, and that it will not be closed as a duplicate /s