[SR-Users] Setting up TLS between proxy and authentication server

[Jijo]

Hi Andrei,

Which version has this change? I don't see it in 3.0.4, the realease note
says that it is fixed. Here is the function

int tls_h_fix_read_conn(struct tcp_connection *c)
{
 int ret;
 struct tls_extra_data* tls_c;

 ret = -1;<=== Isn't it to be zero. Thats what i understood from the patch.
 tls_c = 0;
 if (unlikely(c->extra_data==0)){
  lock_get(&c->write_lock);
   if (unlikely(tls_update_fd(c, c->fd) < 0)){
    ret = -1;
   } else {
    tls_c=(struct tls_extra_data*)c->extra_data;
    switch(tls_c->state){
     case S_TLS_ACCEPTING:
      ret=tls_accept(c, 0);
      break;
     case S_TLS_CONNECTING:
      ret=tls_connect(c, 0);
      break;
     default:
      /* fall through */
      ret=1;
      break;
    }
   }
  lock_release(&c->write_lock);
 } else {
  tls_c=(struct tls_extra_data*)c->extra_data;
  switch (tls_c->state) {
   case S_TLS_ACCEPTING:
    lock_get(&c->write_lock);
     tls_c=(struct tls_extra_data*)c->extra_data;
     /* It might have changed meanwhile */
     if (likely(tls_c->state == S_TLS_ACCEPTING)) {
      ret = tls_update_fd(c, c->fd);
      if (ret == 0) ret = tls_accept(c, 0);
      else ret = -1;
     }
    lock_release(&c->write_lock);
   break;
   case S_TLS_CONNECTING:
    lock_get(&c->write_lock);
     tls_c=(struct tls_extra_data*)c->extra_data;
     /* It might have changed meanwhile */
     if (likely(tls_c->state == S_TLS_CONNECTING)) {
      ret = tls_update_fd(c, c->fd);
      if (ret == 0) ret = tls_connect(c, 0);
      else ret = -1;
     }
    lock_release(&c->write_lock);
   break;
  default: /* fall through */
   ret=1;
   break;
  }
 }
 return (ret>=0)?(tls_c->state==S_TLS_ESTABLISHED):ret;
}


On Mon, Aug 23, 2010 at 11:00 AM, Couprie Geoffroy <
geoffroy.couprie at atosorigin.com> wrote:

> Hello,
>
> -----Message d'origine-----
> De : Andrei Pelinescu-Onciul [mailto:andrei at iptel.org]
> Envoyé : vendredi 20 août 2010 12:35
> À : Couprie Geoffroy
> Cc : sr-users at lists.sip-router.org
> Objet : Re: [SR-Users] Setting up TLS between proxy and authentication
> server
>
> > On Aug 20, 2010 at 12:32, Andrei Pelinescu-Onciul <andrei at iptel.org>
> wrote:
> > > On Aug 20, 2010 at 10:18, Couprie Geoffroy <
> geoffroy.couprie at atosorigin.com> wrote:
> > > > Hello,
> > > >
> > > > I am testing TLS communication with Kamailio 3.0.2, and I encounter a
> strange problem. My setup is like this:
> > > >
> > > > Client      <-UDP->  Proxy server <- TLS with client certificate
> authentication -> Authentication server
> > > > 192.168.24.1            192.168.24.128
>                                                             > 192.168.24.129
> > > >
> > > > The two servers are instance of Kamailio 3.0.2
> > > >
> > > > When the client sends a REGISTER, the proxy retransmits the message
> to the authentication server, which sends back  a 401 Unauthorized. But it
> seems the proxy closes the TLS connexion right after forwarding the
> REGISTER, and doesn't receive the 401 message. The TLS handshake is OK, and
> the client certificate is required (I didn't add the verification part yet).
> The REGISTER message goes through TLS, and is received by the authentication
> server. Then, the proxy sends a TLS alert (Close-notify), and after that
> message, the authentication server sends back the 401, and the proxy ignores
> that message.
> > > >
> > > > Could it be caused by a timeout? Is there a way to keep the TLS
> connection opened?
> > >
> > > It looks like a bug.
> > > Could you try the attached patch and report back if it fixes the
> > > problem?
> >
> > Sorry, forgot to actually attach it. Here it is.
>
> This patch fixed my problem. Now the proxy receives and retransmits the
> 401. Thank you very much!
>
> Best regards,
>
> Geoffroy
>
>
> Ce message et les pièces jointes sont confidentiels et réservés à l'usage
> exclusif de ses destinataires. Il peut également être protégé par le secret
> professionnel. Si vous recevez ce message par erreur, merci d'en avertir
> immédiatement l'expéditeur et de le détruire. L'intégrité du message ne
> pouvant être assurée sur Internet, la responsabilité du groupe Atos Origin
> ne pourra être recherchée quant au contenu de ce message. Bien que les
> meilleurs efforts soient faits pour maintenir cette transmission exempte de
> tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa
> responsabilité ne saurait être recherchée pour tout dommage résultant d'un
> virus transmis.
>
> This e-mail and the documents attached are confidential and intended solely
> for the addressee; it may also be privileged. If you receive this e-mail in
> error, please notify the sender immediately and destroy it. As its integrity
> cannot be secured on the Internet, the Atos Origin group liability cannot be
> triggered for the message content. Although the sender endeavours to
> maintain a computer virus-free network, the sender does not warrant that
> this transmission is virus-free and will not be liable for any damages
> resulting from any virus transmitted.
>
>
>  _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20101029/ec89112a/attachment.htm>