[jitsi-dev] [jitsi-commits] master: Don't try to authenticate on 403 responses (RFC 3261, 21.4.4) (18619e7)

#1

Hey Ingo,

Could you please explain this?

Emil

···

On Sat, Jan 11, 2014 at 6:21 PM, <ingo@jitsi.org> wrote:

Repository : ssh://lists.jitsi.org/jitsi

On branch : master
Link : https://github.com/jitsi/jitsi/compare/24e3a01ac0607e6d66df5c35ddfa6fe92671bd9b...18619e74027240e8a151379757a0b0fbff955b96

---------------------------------------------------------------

commit 18619e74027240e8a151379757a0b0fbff955b96
Author: Ingo Bauersachs <ingo@jitsi.org>
Date: Sat Jan 11 17:21:07 2014 +0100

    Don't try to authenticate on 403 responses (RFC 3261, 21.4.4)

---------------------------------------------------------------

18619e74027240e8a151379757a0b0fbff955b96
.../impl/protocol/sip/SipRegistrarConnection.java | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/src/net/java/sip/communicator/impl/protocol/sip/SipRegistrarConnection.java b/src/net/java/sip/communicator/impl/protocol/sip/SipRegistrarConnection.java
index e928b95..1b9c313 100644
--- a/src/net/java/sip/communicator/impl/protocol/sip/SipRegistrarConnection.java
+++ b/src/net/java/sip/communicator/impl/protocol/sip/SipRegistrarConnection.java
@@ -872,11 +872,9 @@ public class SipRegistrarConnection
         }
         //401 UNAUTHORIZED,
         //407 PROXY_AUTHENTICATION_REQUIRED,
- //403 FORBIDDEN
         else if (response.getStatusCode() == Response.UNAUTHORIZED
                 >> response.getStatusCode()
- == Response.PROXY_AUTHENTICATION_REQUIRED
- || response.getStatusCode() == Response.FORBIDDEN)
+ == Response.PROXY_AUTHENTICATION_REQUIRED)
         {
             processAuthenticationChallenge(
                     clientTransaction, response, sourceProvider);

_______________________________________________
commits mailing list
commits@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/commits

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31

#2

http://lists.jitsi.org/pipermail/dev/2014-January/019520.html

And well, the RFC reference.

Ingo

From: commits-bounces@jitsi.org [mailto:commits-bounces@jitsi.org] On

Behalf

Of Emil Ivov
Sent: Samstag, 11. Januar 2014 20:34
To: Jitsi Mailman
Cc: Jitsi Mailman
Subject: Re: [jitsi-commits] master: Don't try to authenticate on 403
responses (RFC 3261, 21.4.4) (18619e7)
Hey Ingo,

Could you please explain this?

Emil

Repository : ssh://lists.jitsi.org/jitsi

On branch : master
Link :

https://github.com/jitsi/jitsi/compare/24e3a01ac0607e6d66df5c35ddfa6fe92671b
d

···

-----Original Message-----
On Sat, Jan 11, 2014 at 6:21 PM, <ingo@jitsi.org> wrote:

9b...18619e74027240e8a151379757a0b0fbff955b96

#3

The point of handling a 403 is to allow users to react to a wrong
password. A number of servers (such as Asterisk) return 403 for a bad
password.

The endless loop you describe does sound like a problem of course. If
that happens Jitsi should retry once and then remove any stored
passwords and ask the user for credentials at which point a "Cancel"
should break the loop. If this wasn't happening there must have been
an issue but I don't think that removing 403 handling is the right way
to address it.

Emil

···

On Sat, Jan 11, 2014 at 9:38 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

http://lists.jitsi.org/pipermail/dev/2014-January/019520.html

And well, the RFC reference.

Ingo

-----Original Message-----
From: commits-bounces@jitsi.org [mailto:commits-bounces@jitsi.org] On

Behalf

Of Emil Ivov
Sent: Samstag, 11. Januar 2014 20:34
To: Jitsi Mailman
Cc: Jitsi Mailman
Subject: Re: [jitsi-commits] master: Don't try to authenticate on 403
responses (RFC 3261, 21.4.4) (18619e7)
Hey Ingo,

Could you please explain this?

Emil

On Sat, Jan 11, 2014 at 6:21 PM, <ingo@jitsi.org> wrote:

Repository : ssh://lists.jitsi.org/jitsi

On branch : master
Link :

https://github.com/jitsi/jitsi/compare/24e3a01ac0607e6d66df5c35ddfa6fe92671b
d

9b...18619e74027240e8a151379757a0b0fbff955b96

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31

#4

The point of handling a 403 is to allow users to react to a wrong
password. A number of servers (such as Asterisk) return 403 for a bad
password.

Well, okay, then this was a (necessary) workaround. The RFC is pretty clear.

The endless loop you describe does sound like a problem of course. If
that happens Jitsi should retry once and then remove any stored
passwords and ask the user for credentials at which point a "Cancel"
should break the loop. If this wasn't happening there must have been
an issue but I don't think that removing 403 handling is the right way
to address it.

The sip.us 403 message doesn't include a challenge, hence no password dialog
to cancel the loop. Well, I'll look at it again so that we fail if there's
no challenge.

Emil

Ingo

#5

403s don't usually have a challenge, so this isn't going to change
much. IIRC, the thinking here was that resending a request after a 403
brings us back to a 401/407.

Emil

···

On Sat, Jan 11, 2014 at 10:02 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

The point of handling a 403 is to allow users to react to a wrong
password. A number of servers (such as Asterisk) return 403 for a bad
password.

Well, okay, then this was a (necessary) workaround. The RFC is pretty clear.

The endless loop you describe does sound like a problem of course. If
that happens Jitsi should retry once and then remove any stored
passwords and ask the user for credentials at which point a "Cancel"
should break the loop. If this wasn't happening there must have been
an issue but I don't think that removing 403 handling is the right way
to address it.

The sip.us 403 message doesn't include a challenge, hence no password dialog
to cancel the loop. Well, I'll look at it again so that we fail if there's
no challenge.

#6

The point of handling a 403 is to allow users to react to a wrong
password. A number of servers (such as Asterisk) return 403 for a bad
password.

Well, okay, then this was a (necessary) workaround. The RFC is pretty
clear.

The endless loop you describe does sound like a problem of course. If
that happens Jitsi should retry once and then remove any stored
passwords and ask the user for credentials at which point a "Cancel"
should break the loop. If this wasn't happening there must have been
an issue but I don't think that removing 403 handling is the right way
to address it.

The sip.us 403 message doesn't include a challenge, hence no password
dialog to cancel the loop. Well, I'll look at it again so that we fail
if there's no challenge.

403s don't usually have a challenge, so this isn't going to change
much. IIRC, the thinking here was that resending a request after a 403
brings us back to a 401/407.

Yes, right. The commit message is wrong, it is actually checked if there was
no realm on the request that caused the 403. What I currently see with an
Asterisk 11.6/11.7 is:
1) Register (no auth)
2) 401 Unauthorized (with www-authenticate+realm)
3) Register (with authorization to realm from 401)
4) 403 Forbidden (due to wrong login, no realm)
5) (Jitsi asking for username+password)
6) Restart at 1

With sip.us:
1) Register (no auth)
2) 403 Forbidden (no www-authenticate)
3) abort of connection (due to no realm on initial register)

Do you see something wrong with that? If so, could you please give me an
example?

Emil

Ingo

···

On Sat, Jan 11, 2014 at 10:02 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

#7

I think that's exactly the way to address it. Thanks!

Emil

···

On Sun, Jan 12, 2014 at 1:51 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

Yes, right. The commit message is wrong, it is actually checked if there was
no realm on the request that caused the 403. What I currently see with an
Asterisk 11.6/11.7 is:
1) Register (no auth)
2) 401 Unauthorized (with www-authenticate+realm)
3) Register (with authorization to realm from 401)
4) 403 Forbidden (due to wrong login, no realm)
5) (Jitsi asking for username+password)
6) Restart at 1

With sip.us:
1) Register (no auth)
2) 403 Forbidden (no www-authenticate)
3) abort of connection (due to no realm on initial register)

Do you see something wrong with that? If so, could you please give me an
example?

--
https://jitsi.org

#8

It's interesting but since this change Jitsi gets to forget my
password at least twice a day. We'd have to look into this.

···

On Sun, Jan 12, 2014 at 3:08 PM, Emil Ivov <emcho@jitsi.org> wrote:

On Sun, Jan 12, 2014 at 1:51 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

Yes, right. The commit message is wrong, it is actually checked if there was
no realm on the request that caused the 403. What I currently see with an
Asterisk 11.6/11.7 is:
1) Register (no auth)
2) 401 Unauthorized (with www-authenticate+realm)
3) Register (with authorization to realm from 401)
4) 403 Forbidden (due to wrong login, no realm)
5) (Jitsi asking for username+password)
6) Restart at 1

With sip.us:
1) Register (no auth)
2) 403 Forbidden (no www-authenticate)
3) abort of connection (due to no realm on initial register)

Do you see something wrong with that? If so, could you please give me an
example?

I think that's exactly the way to address it. Thanks!

Emil

--
https://jitsi.org

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31

#9

Subject: Re: [jitsi-dev] [jitsi-commits] master: Don't try to authenticate

on

403 responses (RFC 3261, 21.4.4) (18619e7)
It's interesting but since this change Jitsi gets to forget my
password at least twice a day. We'd have to look into this.

I never lost a password for SIP (contrary to XMPP, which regularly asks for
the password when there's a server hiccup). Are you sure it's commit
4899b4127bcce25a40abcc4f4e29235fe84e7286 and not maybe the database based
config?

Ingo

#10

Subject: Re: [jitsi-dev] [jitsi-commits] master: Don't try to authenticate

on

403 responses (RFC 3261, 21.4.4) (18619e7)
It's interesting but since this change Jitsi gets to forget my
password at least twice a day. We'd have to look into this.

I never lost a password for SIP (contrary to XMPP, which regularly asks for
the password when there's a server hiccup).

Yes, same experience for XMPP.

Are you sure it's commit
4899b4127bcce25a40abcc4f4e29235fe84e7286 and not maybe the database based
config?

I am sure it's not the database config because. I haven't bisected so
I can't be 100% certain that the auth commit is at the root of this
but I feel quite confident this is when I started seeing it.

···

On Wed, Feb 12, 2014 at 3:08 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

--
https://jitsi.org

#11

Can you please send me the pcap over next time it happens?

Freundliche Grüsse,
Ingo Bauersachs

-- sent from my mobile

···

Le 12.02.2014 à 17:46, "Emil Ivov" <emcho@jitsi.org> a écrit :

On Wed, Feb 12, 2014 at 3:08 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

Subject: Re: [jitsi-dev] [jitsi-commits] master: Don't try to authenticate

on

403 responses (RFC 3261, 21.4.4) (18619e7)
It's interesting but since this change Jitsi gets to forget my
password at least twice a day. We'd have to look into this.

I never lost a password for SIP (contrary to XMPP, which regularly asks for
the password when there's a server hiccup).

Yes, same experience for XMPP.

Are you sure it's commit
4899b4127bcce25a40abcc4f4e29235fe84e7286 and not maybe the database based
config?

I am sure it's not the database config because. I haven't bisected so
I can't be 100% certain that the auth commit is at the root of this
but I feel quite confident this is when I started seeing it.

--
https://jitsi.org

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev