summaryrefslogtreecommitdiff
path: root/res/res_pjsip_authenticator_digest.c
AgeCommit message (Collapse)Author
2018-01-24Remove redundant module checks and references.Corey Farrell
This removes references that are no longer needed due to automatic references created by module dependencies. In addition this removes most calls to ast_module_check as they were checking modules which are listed as dependencies. Change-Id: I332a6e8383d4c72c8e89d988a184ab8320c4872e
2018-01-15loader: Add dependency fields to module structures.Corey Farrell
* Declare 'requires' and 'enhances' text fields on module info structure. * Rename 'nonoptreq' to 'optional_modules'. * Update doxygen comments. Still need to investigate dependencies among modules I cannot compile. Change-Id: I3ad9547a0a6442409ff4e352a6d897bef2cc04bf
2017-02-20res_pjsip_authenticator_digest.c: Fix sorcery's immutable contract violation.Richard Mudgett
The inbound authentication object is supposed to be immutable when it is stored in sorcery. However, the immutable property is violated if the authentication object does not have a realm set. The immutable contract violation has a different effect depending upon what sorcery back end is used. If it is the config file back end you would get the same object back until res_pjsip is reloaded. If it is the real-time or AstDB back end you would get a new object on each query. If it is cached you would get the same object back until it is refreshed from the database. Once an inbound authentication object has its realm set it may or may not get updated again if the default_realm changes. If the same authentication object is used for inbound and outbound authentication then the immutable violation can make it very hard to determine why the outbound authentication now fails. The only diagnostic message is a complaint about no realms matching when it had worked earlier. It fails because of the difference in behaviour for an empty realm setting between inbound and outbound authentication objects. * Fixed the sorcery object immutable violation by creating a new object and setting the default_realm on it instead. The new object is a shallow copy for speed. * The auth_store thread storage no longer holds an auth ref. It interferes with the shallow copy and never needed a ref anyway. ASTERISK-26799 #close Change-Id: I2328a52f61b78ed5fbba38180b7f183ee7e08956
2016-05-09res_pjsip_authenticator_digest: Don't use source port in nonce verificationKevin Harwell
From the issue reporter: "res_pjsip_outbound_authenticator_digest builds a nonce that is a hash of the timestamp, the source address, the source port, a server UUID that is calculated at startup, and the authentication realm. Rather than caching nonces that we create, we instead attempt to re-calculate the nonce when receiving an incoming request with authentication. We then compare the re-calculated nonce to the incoming nonce, and if they don't match, then authentication has failed early. The problem is that it is possible, especially when using TCP, to receive two requests from the same endpoint but have differing source ports for those requests. Asterisk itself commonly will use different source ports for outbound TCP requests." This patch removes the source port dependency when building the nonce. ASTERISK-25978 #close Change-Id: I871b5f4adce102df1c4988066283095ec509dffe
2016-05-06res_pjsip: module load priorityAlexei Gradinari
The res_pjsip_authenticator_digest, res_pjsip_endpoint_identifier_* and res_pjsip_registrar modules should load ASAP to avoid "No matching endpoint found" for legitimate endpoint. ASTERISK-25994 Change-Id: Iac95d95ad031e0be104189d29e923a2ad7c24a1b
2016-04-27res_pjsip: Add ability to identify by Authorization usernameGeorge Joseph
A feature of chan_sip that service providers relied upon was the ability to identify by the Authorization username. This is most often used when customers have a PBX that needs to register rather than identify by IP address. From my own experiance, this is pretty common with small businesses who otherwise don't need a static IP. In this scenario, a register from the customer's PBX may succeed because From will usually contain the PBXs account id but an INVITE will contain the caller id. With nothing recognizable in From, the service provider's Asterisk can never match to an endpoint and the INVITE just stays unauthorized. The fixes: A new value "auth_username" has been added to endpoint/identify_by that will use the username and digest fields in the Authorization header instead of username and domain in the the From header to match an endpoint, or the To header to match an aor. This code as added to res_pjsip_endpoint_identifier_user rather than creating a new module. Although identify_by was always a comma-separated list, there was only 1 choice so order wasn't preserved. So to keep the order, a vector was added to the end of ast_sip_endpoint. This is only used by res_pjsip_registrar to find the aor. The res_pjsip_endpoint_identifier_* modules are called in globals/endpoint_identifier_order. Along the way, the logic in res_pjsip_registrar was corrected to match most-specific to least-specific as res_pjsip_endpoint_identifier_user does. The order is: username@domain username@domain_alias username Auth by username does present 1 problem however, the first INVITE won't have an Authorization header so the distributor, not finding a match on anything, sends a securty_alert. It still sends a 401 with a challenge so the next INVITE will have the Authorization header and presumably succeed. As a result though, that first security alert is actually a false alarm. To address this, a new feature has been added to pjsip_distributor that keeps track of unidentified requests and only sends the security alert if a configurable number of unidentified requests come from the same IP in a configurable amout of time. Those configuration options have been added to the global config object. This feature is only used when auth_username is enabled. Finally, default_realm was added to the globals object to replace the hard coded "asterisk" used when an endpoint is not yet identified. The testsuite tests all pass but new tests are forthcoming for this new feature. ASTERISK-25835 #close Reported-by: Ross Beer Change-Id: I30ba62d208e6f63439600916fcd1c08a365ed69d
2015-05-13AST_MODULE_INFO: Format corrections to the usages of AST_MODULE_INFO macro.Rodrigo Ramírez Norambuena
Change-Id: Icf88f9f861c6b2a16e5f626ff25795218a6f2723
2014-10-16PJSIP: Enforce module load dependenciesKinsey Moore
This enforces that res_pjsip, res_pjsip_session, and res_pjsip_pubsub have loaded properly before attempting to load any modules that depend on them since the module loader system is not currently capable of resolving module dependencies on its own. ASTERISK-24312 #close Reported by: Dafi Ni Review: https://reviewboard.asterisk.org/r/4062/ ........ Merged revisions 425690 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 425691 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@425700 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-09-29Simplify UUID generation in several places.Richard Mudgett
Replace code using ast_uuid_generate() with simpler and faster code using ast_uuid_generate_str(). The new code avoids a malloc(), free(), and copy. ........ Merged revisions 424103 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 424105 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@424109 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-25Add module support level to ast_module_info structure. Print it in CLI ↵Mark Michelson
"module show" . ASTERISK-23919 #close Reported by Malcolm Davenport Review: https://reviewboard.asterisk.org/r/3802 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419592 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-01-03res_pjsip_authenticator_digest: Fix md5 hash bufferMatthew Jordan
An md5 hash is 32 bytes long. The char buffer must be at least 33 bytes to avoid clobbering of the stack. This patch also fixes a potential clobbering in test_utils.c. Thanks to Andrew Nagy for reporting and testing this out in #asterisk-dev Reported by: Andrew Nagy Tested by: Andrew Nagy ........ Merged revisions 404843 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404844 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-12-10Fix correct authentication behavior for artificial endpoint.Mark Michelson
When switching to using a vector for authentication, I initialized the vector for the artificial endpoint to be of size 1. However, this does not result in AST_VECTOR_SIZE() returning 1 since there isn't actually anything in the vector. Rather than trifle with the vector by putting unnecessary elements in, I simply changed the callback in res_pjsip_authenticator_digest.c to explicitly report that the artificial endpoint requires authentication. Thanks to Joshua Colp for pointing this out. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403605 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-12-09Switch PJSIP auth to use a vector.Mark Michelson
Since Asterisk has a vector API now, places where arrays are manually resized don't really make sense any more. Since the auth work in PJSIP was freshly-written, it was easy to reform it to use a vector. Review: https://reviewboard.asterisk.org/r/3044 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403499 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-11-07PJSIP: Improve error handling in digest authenticatorJonathan Rose
Previously, regardless of whether failure to authenticate was due to lacking any authentication or actually failing authentication, the Digest Authenticator would simply return that a challenge was still needed. It will continue to do that when no authentication information is in the received SIP digest, but when authentication information is present and does not pass authentication, that will be treated as an authentication error. This is to ensure that PJSIP will issue security events indicated failed auths. ........ Merged revisions 402537 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402538 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-09-13Change how realms are handled for outbound authentication.Mark Michelson
With this change, if no realm is specified in an outbound auth section, then we will simply match the realm that was present in the 401/407 challenge. (closes issue ASTERISK-22471) Reported by George Joseph (closes issue ASTERISK-22386) Reported by Rusty Newton Patches: outbound_auth_realm_v4.patch uploaded by George Joseph (License #6322) ........ Merged revisions 399059 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399082 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-30The large GULP->PJSIP renaming effort.Mark Michelson
The general gist is to have a clear boundary between old SIP stuff and new SIP stuff by having the word "SIP" for old stuff and "PJSIP" for new stuff. Here's a brief rundown of the changes: * The word "Gulp" in dialstrings, functions, and CLI commands is now "PJSIP" * chan_gulp.c is now chan_pjsip.c * Function names in chan_gulp.c that were "gulp_*" are now "chan_pjsip_*" * All files that were "res_sip*" are now "res_pjsip*" * The "res_sip" directory is now "res_pjsip" * Files in the "res_pjsip" directory that began with "sip_*" are now "pjsip_*" * The configuration file is now "pjsip.conf" instead of "res_sip.conf" * The module info for all PJSIP-related files now uses "PJSIP" instead of "SIP" * CLI and AMI commands created by Asterisk's PJSIP modules now have "pjsip" as the starting word instead of "sip" git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395764 65c4cc65-6c06-0410-ace0-fbb531ad65f3