Bug #7206
closedAuthentication Method Used in Bug 6751 Removed by Amazon
100%
Description
It appears that Route53 has stopped working with the AWS3-HTTP authentication method sometime in the last month. This was the authentication used to resolve Bug #6751. That authentication was an older API. While I cannot find any record it went away, my region/Route53 service no longer works. This bug is being opened to provide a patch to implement the "Signing Version 4" authentication in r53.class and dyndns.class.
The reason I did not previously use Signing Version 4 is that v4 requires the region code (e.g. us-east-1, eu-west-1, etc.). However what will now be required is a change in the configuration of the Dynamic DNS entry for Amazon Route53. When now entering "Zone ID", for Route54 the zone will have to be specified in the format "REGION/ZONE" - e.g. "us-east-1/JAUTQ3JSAK". Not sure how this will need to be documented in the release notes.
I am working on a patch for this now but wanted to raise visibility of this issue.
Files
Updated by Jason McCormick over 7 years ago
Service no longer works in that is receives a signing error even though all details are correct.
Updated by Jason McCormick over 7 years ago
I've tested changes and created a pull request to resolve this issue: https://github.com/pfsense/pfsense/pull/3473.
Again please note the need to change how the Zone ID field now requires the region prepended to the zone ID. This seems cleaner than trying to shoehorn another field in no one but Route53 users will use. However this will have to be documented well in the release notes somehow.
Updated by Jason McCormick over 7 years ago
Also, wanted to note that the use of v4 signing enables newer regions that didn't support the legacy authentication type.
Updated by Renato Botelho over 7 years ago
- Status changed from New to Feedback
- Assignee set to Renato Botelho
- Priority changed from High to Normal
- % Done changed from 50 to 100
PR has been merged, thanks!
Updated by Doug Twitchell over 7 years ago
I tried it, but received an error. Here's the log with redactions:
/services_dyndns_edit.php: phpDynDNS (home.example.com): (Error) Route53 API call failed /services_dyndns_edit.php: error message: <?xml version="1.0"?> <ErrorResponse xmlns="https://route53.amazonaws.com/doc/2013-04-01/"><Error><Type>Sender</Type><Code>SignatureDoesNotMatch</Code><Message>The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details. The Canonical String for this request should have been 'POST /2013-04-01/hostedzone/XXXXXXXXXXX/rrset content-type:text/xml host:route53.amazonaws.com x-amz-date:20170302T021712Z content-type;host;x-amz-date bd949ca9fd38158acb171c46732a582b4c09bf43839ae2588fb76106c0315f9f' The String-to-Sign should have been 'AWS4-HMAC-SHA256 20170302T021712Z 20170302/us-east-1/route53/aws4_request 011e7fcf0327585f97382de6196e1b2af584dc9412a62a0da582363a88520bfa' </Message></Error><RequestId>58aad100-feee-11e6-b0df-ed7636b544a0</RequestId></ErrorResponse> /services_dyndns_edit.php: Dynamic DNS route53 (home.example.com): _checkStatus() starting. /services_dyndns_edit.php: XMLPOST: <?xml version="1.0" encoding="UTF-8"?><ChangeResourceRecordSetsRequest xmlns="https://route53.amazonaws.com/doc/2013-04-01/"><ChangeBatch><Changes><Change><Action>UPSERT</Action><ResourceRecordSet><Name>home.example.com</Name><Type>A</Type><TTL>3600</TTL><ResourceRecords><ResourceRecord><Value>XXX.XXX.XXX.XXX</Value></ResourceRecord></ResourceRecords></ResourceRecordSet></Change></Changes></ChangeBatch></ChangeResourceRecordSetsRequest> /services_dyndns_edit.php: Header: Authorization: AWS4-HMAC-SHA256 Credential=XXXXXXXXXXXXXXXXXXXX/20170302/us-east-1/route53/aws4_request, SignedHeaders=content-type;host;x-amz-date, Signature=f6c6b226426515071d2d853fbbb4b4d2e948a732f29a709284c36219bf3f6cc6
It tried it with two different sets of credentials.
Also, as far as I can tell, since Route 53 is global in scope, the region used for credentials is always us-east-1. In their request template in the docs us-east-1 is not in red and should therefore be constant.
Updated by Jim Pingle over 7 years ago
- Status changed from Feedback to New
- Assignee changed from Renato Botelho to Jason McCormick
Updated by Jason McCormick over 7 years ago
I've looked for evidence that the only Route53 region is US-EAST-1 and I've never been able to find a definitive statement about that. The documentation seems to imply that but I didn't want to make a false assumption on that. It's easy to hard-code that if it's true, but I'd like to see real documentation that effect. I'll have to look again.
That error you're getting is an incorrect public/secret key pairing. I've had a weird problem with the Pfsense UI + Firefox inserting a space at the end of pasting in some fields. Make sure you don't have an extra space at the end of any of the Dyndns fields. I'll dig up the test harness code I wrote to test this and send it to you.
Updated by Jason McCormick over 7 years ago
- File r53-dyndns-clean.php r53-dyndns-clean.php added
NOT THIS ONE
Updated by Jason McCormick over 7 years ago
- File r53-dyndns-clean.php r53-dyndns-clean.php added
You can use the attached PHP script to test r53.class. I just ran everything through its paces and didn't have any issues. I'd appreciate any debugging you can aid to see where your setup is different. Replace the strings PUBKEY, PRIVKEY, ZONEID (2x), and set whatever DNS makes sense for you on line 16.
Note: Use this test, not the one in the comment above. I attached the wrong file (the other one has some testing I was starting to do to support AAAA records).
Updated by Doug Twitchell over 7 years ago
I created new credentials and it worked this time. I'm not sure what went wrong before. Is there any chance that certain base64 characters like "=" or "/" could cause a problem?
I'll try out the test code and let you know if I find anything, but for now I'd say it works.
Concerning the region, this site shows Route 53 API endpoints only existing in us-east-1: [[http://docs.aws.amazon.com/general/latest/gr/rande.html#r53_region]]. Putting in the us-east-1 in the form is not a big deal, but if we don't need to do it, it would make it less confusing. I'm no AWS expert, so independent confirmation that us-east-1 is the only region for Route 53 would be nice.
Updated by Jason McCormick over 7 years ago
Glad you got it working. There shouldn't be anything coding unsafe with base64. Feel free to look through the signature generation code but every string is hashed and the final output is encoded so it should be HTTP-safe.
Thanks for digging up that link about us-east-1. I never came across that before so that seems pretty definitive. I'll update this branch in Github to remove the need to change the UI to add the region.
Updated by Jason McCormick over 7 years ago
Here's a diff on my pfsense fork: https://github.com/pfsense/pfsense/compare/master...jxmx:7206_route53
I don't have any more time to test this tonight but it should work just fine - changes are trivial. I'll test this over the weekend and make a new pull request on the master repo.
Updated by Jason McCormick over 7 years ago
Okay I've done more testing with this and I'm getting more random errors that don't make any sense to me. The same code used with the standalone PHP script I included here works flawlessly. However the same calls from the dyndns.class yield non-deterministic behavior. Some of my Route53 entries work (at one point they all did!), yet some don't now. But they're all using the same IAM keypair. If I add a new entry, it uniformly fails. But Doug you reported you added one and it started working. So now I'm very confused.
Updated by Jason McCormick over 7 years ago
It helps if I completely reverted the items I changed for the region being added to the zone. Just needed to step away from the code for a bit. I've tested this with existing and new entries and everything works now. Doug, if you could give this diff a whirl.
https://github.com/pfsense/pfsense/compare/master...jxmx:7206_route53
Updated by Doug Twitchell over 7 years ago
Applied the patch. It works. Thanks!
Updated by Jim Pingle over 7 years ago
- Status changed from New to Resolved
PR was merged months ago, no recent complaints. Should be OK.
https://github.com/pfsense/pfsense/pull/3608