Project

General

Profile

Bug #7206

Authentication Method Used in Bug 6751 Removed by Amazon

Added by Jason McCormick 10 months ago. Updated 5 months ago.

Status:
Resolved
Priority:
Normal
Category:
Dynamic DNS
Target version:
Start date:
02/03/2017
Due date:
% Done:

100%

Affected Version:
2.4
Affected Architecture:
All

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.

r53-dyndns-clean.php Magnifier - testkit for r53.class (849 Bytes) Jason McCormick, 03/02/2017 07:54 PM

r53-dyndns-clean.php Magnifier (845 Bytes) Jason McCormick, 03/02/2017 07:58 PM

History

#1 Updated by Jason McCormick 10 months ago

Service no longer works in that is receives a signing error even though all details are correct.

#2 Updated by Jason McCormick 10 months 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.

#3 Updated by Jason McCormick 10 months ago

Also, wanted to note that the use of v4 signing enables newer regions that didn't support the legacy authentication type.

#4 Updated by Renato Botelho 10 months 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!

#5 Updated by Doug Twitchell 9 months 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.

#6 Updated by Jim Pingle 9 months ago

  • Status changed from Feedback to New
  • Assignee changed from Renato Botelho to Jason McCormick

#7 Updated by Jason McCormick 9 months 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.

#8 Updated by Jason McCormick 9 months ago

NOT THIS ONE

#9 Updated by Jason McCormick 9 months ago

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).

#10 Updated by Doug Twitchell 9 months 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.

#11 Updated by Jason McCormick 9 months 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.

#12 Updated by Jason McCormick 9 months 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.

#13 Updated by Jason McCormick 9 months 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.

#14 Updated by Jason McCormick 9 months 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

#15 Updated by Jason McCormick 9 months ago

Pull #3608

#16 Updated by Doug Twitchell 9 months ago

Applied the patch. It works. Thanks!

#17 Updated by Jim Pingle 5 months 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

Also available in: Atom PDF