starred/dehydrated
1
0
Fork 0
mirror of https://github.com/dehydrated-io/dehydrated.git synced 2026-01-11 22:30:44 +01:00
Code Issues 79 Packages Projects Releases 10 Wiki Activity

ACME clients SHOULD send unique User-Agent header. #283

New Issue
Closed
opened 2025-12-29 01:21:06 +01:00 by adam · 16 comments
adam commented 2025-12-29 01:21:06 +01:00
Owner
Copy Link

Originally created by @cpu on GitHub (Feb 22, 2018).

Hi @lukas2511 ,

It looks like presently dehydrated doesn't send its own User-Agent header in its ACME requests, instead using the UA set by curl. I did a quick search and it seems like you took a crack at setting one in a5fde931f8 but backed the change out in 197ca8e82c.

Would you consider re-introducing a custom UA for dehydrated? It's a big help for ACME server operators that may be troubleshooting behaviour from server logs & trying to correlate with specific client implementations.

Section 6.1 of the ACME spec even goes as far as to say clients SHOULD set a UA:

ACME clients SHOULD send a User-Agent header in accordance with [RFC7231], including the name and version of the ACME software in addition to the name and version of the underlying HTTP client software.

Thanks!

Originally created by @cpu on GitHub (Feb 22, 2018). Hi @lukas2511 , It looks like presently `dehydrated` doesn't send its own `User-Agent` header in its ACME requests, instead using the UA set by `curl`. I did a quick search and it seems like you took a crack at setting one in https://github.com/lukas2511/dehydrated/commit/a5fde931f8602ec1334e8ad2e3471c6c7ceeb58d but backed the change out in https://github.com/lukas2511/dehydrated/commit/197ca8e82cbf25e4f8218cb1f7f9a0cd407fb494. Would you consider re-introducing a custom UA for `dehydrated`? It's a big help for ACME server operators that may be troubleshooting behaviour from server logs & trying to correlate with specific client implementations. [Section 6.1](https://tools.ietf.org/html/draft-ietf-acme-acme-09#section-6.1) of the ACME spec even goes as far as to say clients SHOULD set a UA: > ACME clients SHOULD send a User-Agent header in accordance with [RFC7231], including the name and version of the ACME software in addition to the name and version of the underlying HTTP client software. Thanks!
adam closed this issue 2025-12-29 01:21:06 +01:00
adam commented 2025-12-29 01:21:08 +01:00
Author
Owner
Copy Link

@lukas2511 commented on GitHub (Feb 22, 2018):

Well... the reason is as follows:

Ξ ~ → curl https://acme-staging-v02.api.letsencrypt.org/directory -A "curl/7.58.0 dehydrated/0.5.0" 
<HTML><HEAD>
<TITLE>Access Denied</TITLE>

But...

Ξ ~ → curl https://acme-staging-v02.api.letsencrypt.org/directory -A "curl/7.58.0 dehyd/0.5.0"  
{
  "9vyBT0DoJ8E": "https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417",
  "keyChange": "https://acme-staging-v02.api.letsencrypt.org/acme/key-change",
  "meta": {

I'm not sure what's going on there, but it seems that hydra is somehow blacklisted in the WAF... So I can't possible include the name of my client without everything breaking ;)

@lukas2511 commented on GitHub (Feb 22, 2018): Well... the reason is as follows: ``` Ξ ~ → curl https://acme-staging-v02.api.letsencrypt.org/directory -A "curl/7.58.0 dehydrated/0.5.0" <HTML><HEAD> <TITLE>Access Denied</TITLE> ``` But... ``` Ξ ~ → curl https://acme-staging-v02.api.letsencrypt.org/directory -A "curl/7.58.0 dehyd/0.5.0" { "9vyBT0DoJ8E": "https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417", "keyChange": "https://acme-staging-v02.api.letsencrypt.org/acme/key-change", "meta": { ``` I'm not sure what's going on there, but it seems that `hydra` is somehow blacklisted in the WAF... So I can't possible include the name of my client without everything breaking ;)
adam commented 2025-12-29 01:21:08 +01:00
Author
Owner
Copy Link

@cpu commented on GitHub (Feb 22, 2018):

@lukas2511 Ugh 💢. I'll ask our operations team to see if there's something in the Akamai configuration that causes this.

@cpu commented on GitHub (Feb 22, 2018): @lukas2511 Ugh :anger:. I'll ask our operations team to see if there's something in the Akamai configuration that causes this.
adam commented 2025-12-29 01:21:08 +01:00
Author
Owner
Copy Link

@cpu commented on GitHub (Feb 22, 2018):

@lukas2511 They're going to look into this over the next day or two. I'll keep you updated here.

Going forward, please feel free to flag this sort of API issue on the Boulder repo or in the community forum. I definitely had no idea this was happening! 😆

@cpu commented on GitHub (Feb 22, 2018): @lukas2511 They're going to look into this over the next day or two. I'll keep you updated here. Going forward, please feel free to flag this sort of API issue on the [Boulder repo](https://github.com/letsencrypt/boulder) or in the [community forum](https://community.letsencrypt.org). I definitely had no idea this was happening! :laughing:
adam commented 2025-12-29 01:21:09 +01:00
Author
Owner
Copy Link

@lukas2511 commented on GitHub (Mar 1, 2018):

I added a temporary user agent with letter replacement (68274646bb). I guess this makes dehydr4ted the most 1337 client option available.

@cpu any update on this?

@lukas2511 commented on GitHub (Mar 1, 2018): I added a temporary user agent with letter replacement (68274646bbb40e733d9fb5f3b0590d124a3aaea9). I guess this makes dehydr4ted the most 1337 client option available. @cpu any update on this?
adam commented 2025-12-29 01:21:09 +01:00
Author
Owner
Copy Link

@cpu commented on GitHub (Mar 1, 2018):

I guess this makes dehydr4ted the most 1337 client option available.

Haha. 🏆 💻

@cpu any update on this?

I poked our operations team about this again this morning and its on their radar but hasn't been addressed yet. If you'd like I can close this issue for now and reopen it when I've heard back. I promise I won't forget, it's in my notebook every day :-)

@cpu commented on GitHub (Mar 1, 2018): > I guess this makes dehydr4ted the most 1337 client option available. Haha. :trophy: :computer: > @cpu any update on this? I poked our operations team about this again this morning and its on their radar but hasn't been addressed yet. If you'd like I can close this issue for now and reopen it when I've heard back. I promise I won't forget, it's in my notebook every day :-)
adam commented 2025-12-29 01:21:09 +01:00
Author
Owner
Copy Link

@cpu commented on GitHub (Mar 9, 2018):

Quick update: There's a change being staged that should resolve this in the next few days. I'll comment again when the change is active for staging/prod. Thanks!

@cpu commented on GitHub (Mar 9, 2018): Quick update: There's a change being staged that should resolve this in the next few days. I'll comment again when the change is active for staging/prod. Thanks!
adam commented 2025-12-29 01:21:10 +01:00
Author
Owner
Copy Link

@cpu commented on GitHub (Mar 12, 2018):

@lukas2511 Good news, I'm told the functionality causing the "hydra" substring block is disabled now. I'm not able to replicate it as before. You should be able to drop your 31337 spelling now :-)

@cpu commented on GitHub (Mar 12, 2018): @lukas2511 Good news, I'm told the functionality causing the "hydra" substring block is disabled now. I'm not able to replicate it as before. You should be able to drop your 31337 spelling now :-)
adam commented 2025-12-29 01:21:11 +01:00
Author
Owner
Copy Link

@lukas2511 commented on GitHub (Mar 12, 2018):

@cpu Mh, I just checked, it works for the ACMEv2 staging environment, but not for production and the old staging environment :-/

@lukas2511 commented on GitHub (Mar 12, 2018): @cpu Mh, I just checked, it works for the ACMEv2 staging environment, but not for production and the old staging environment :-/
adam commented 2025-12-29 01:21:11 +01:00
Author
Owner
Copy Link

@cpu commented on GitHub (Mar 12, 2018):

@lukas2511 Blech! The V2 environment is the one I used to spot-check the fix. Thanks, I'll pass this feedback along.

@cpu commented on GitHub (Mar 12, 2018): @lukas2511 Blech! The V2 environment is the one I used to spot-check the fix. Thanks, I'll pass this feedback along.
adam commented 2025-12-29 01:21:11 +01:00
Author
Owner
Copy Link

@lukas2511 commented on GitHub (Mar 12, 2018):

@cpu Is this something Akamai has in their default blacklist? If that's the case I guess it would be better to just stay with the 31337 spelling... It would be really bad if in the future somebody re-enables a default blacklist and slightly outdated dehydrated versions (cough debian stable cough) would stop working.

@lukas2511 commented on GitHub (Mar 12, 2018): @cpu Is this something Akamai has in their default blacklist? If that's the case I guess it would be better to just stay with the 31337 spelling... It would be really bad if in the future somebody re-enables a default blacklist and slightly outdated dehydrated versions (*cough* debian sta*b*le *cough*) would stop working.
adam commented 2025-12-29 01:21:12 +01:00
Author
Owner
Copy Link

@cpu commented on GitHub (Mar 12, 2018):

@lukas2511 I'll have to confirm with our ops team (I don't have any visibility into Akamai settings). I believe it's part of the default WAF rules, I don't know if the WAF is enabled by default for Akamai customers. It's a very silly/naive rule that I expect was originally meant to deal with thc-hydra, an old tool for running online password guessing attacks.

The plan I've advocated that I believe is in-progress is to remove the WAF outright for API traffic: We don't benefit from the WAF in a way that justifies the surprising effects & support burden. Once disabled there shouldn't come a time when it gets reenabled suddenly with the default ruleset.

Thanks for your patience/help!

@cpu commented on GitHub (Mar 12, 2018): @lukas2511 I'll have to confirm with our ops team (I don't have any visibility into Akamai settings). I believe it's part of the default WAF rules, I don't know if the WAF is enabled by default for Akamai customers. It's a very silly/naive rule that I expect was originally meant to deal with `thc-hydra`, an old tool for running online password guessing attacks. The plan I've advocated that I believe is in-progress is to remove the WAF outright for API traffic: We don't benefit from the WAF in a way that justifies the surprising effects & support burden. Once disabled there shouldn't come a time when it gets reenabled suddenly with the default ruleset. Thanks for your patience/help!
adam commented 2025-12-29 01:21:12 +01:00
Author
Owner
Copy Link

@cpu commented on GitHub (Mar 14, 2018):

Another update: The operations team member that was working on this has been out sick for several days. I will update here again when they're back and have had a chance to look into the incomplete fix.

@cpu commented on GitHub (Mar 14, 2018): Another update: The operations team member that was working on this has been out sick for several days. I will update here again when they're back and have had a chance to look into the incomplete fix.
adam commented 2025-12-29 01:21:13 +01:00
Author
Owner
Copy Link

@lukas2511 commented on GitHub (Mar 14, 2018):

@cpu btw. i'm guessing you are generating some kind of internal stats over those user agents, will those ever be published? i'd be really interested in having a good idea about how many people actually use dehydrated for their certificates 😄

@lukas2511 commented on GitHub (Mar 14, 2018): @cpu btw. i'm guessing you are generating some kind of internal stats over those user agents, will those ever be published? i'd be really interested in having a good idea about how many people actually use dehydrated for their certificates :smile:
adam commented 2025-12-29 01:21:13 +01:00
Author
Owner
Copy Link

@cpu commented on GitHub (Mar 14, 2018):

@lukas2511 I was generating some #'s in a pretty adhoc way to satisfy my own curiosity ahead of the public launch of ACME v2. I don't think there has been any discussion about sharing usage statistics with client authors. I'll ask around, maybe I can share some rough #s with you :-)

@cpu commented on GitHub (Mar 14, 2018): @lukas2511 I was generating some #'s in a pretty adhoc way to satisfy my own curiosity ahead of the public launch of ACME v2. I don't think there has been any discussion about sharing usage statistics with client authors. I'll ask around, maybe I can share some rough #s with you :-)
adam commented 2025-12-29 01:21:14 +01:00
Author
Owner
Copy Link

@cpu commented on GitHub (Mar 20, 2018):

@lukas2511 Ok, I think the UA/WAF problem is finally resolved. I'm able to hit the V1 staging env, the V2 staging env, the V1 prod env and the V2 prod env with the Dehydrated UA without any errors. Can you confirm you're seeing the same?

@cpu commented on GitHub (Mar 20, 2018): @lukas2511 Ok, I think the UA/WAF problem is finally resolved. I'm able to hit the V1 staging env, the V2 staging env, the V1 prod env and the V2 prod env with the Dehydrated UA without any errors. Can you confirm you're seeing the same?
adam commented 2025-12-29 01:21:14 +01:00
Author
Owner
Copy Link

@lukas2511 commented on GitHub (Mar 24, 2018):

@cpu I checked again and it seems to be working on all environments now, un-1337-ed in 981179a770, thanks!

@lukas2511 commented on GitHub (Mar 24, 2018): @cpu I checked again and it seems to be working on all environments now, un-1337-ed in 981179a7709aa64c951a4ba293f7a9c3db49e1c0, thanks!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Complicated
bug
enhancement
help wanted
pull-request
Mirrored from GitHub Pull Request
 suggestions wanted
testing
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/dehydrated#283
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?