DISCLAIMER. English language used here only for compatibility (ASCII only), so any suggestions about my bad grammar (and not only it) will be greatly appreciated.

понедельник, 11 июля 2011 г.

This icq..

Upd5. 2012-11-16. Suggested here stunnel config is insecure. See icq through stunnel: enable certificate verification for improvement.

This icq, this damned icq.. doesn't log in! As i expected, though.


There is several bugreports about such problem:

    Debian squeeze Bug  #630254
    Ubuntu Bug #683076

Though, with disabled both SSL and clientLogin pidgin works for me, but this is
not good, right?

Error messages and pidgin versions in these two bugreports is not the same,
but i suppose the problem is the same: incorrect log in server addresses. And
patch mentioned in Ubuntu's bugreport comment 18 (and 21)

    Pidgin ViewMTN/diff between revisions [98ca3d09..] and [99e26392..]

fixes this. But Pidging 2.7.3 from Debian squeeze still uses wrong server
addresses - 'api.screenname.aol.com:443' and 'api.oscar.aol.com:443', - when
trying to log in with SSL and/or clientLogin enabled:

    ..
    (14:09:53) proxy: Attempting connection to 205.188.93.135
    (14:09:53) proxy: Connecting to api.screenname.aol.com:443 with no proxy
    (14:09:53) proxy: Connection in progress
    (14:09:53) proxy: Connecting to api.screenname.aol.com:443.
    (14:09:53) proxy: Connected to api.screenname.aol.com:443.
    ..
    (14:09:54) proxy: Attempting connection to 205.188.100.136
    (14:09:54) proxy: Connecting to api.oscar.aol.com:443 with no proxy
    (14:09:54) proxy: Connection in progress
    (14:09:54) proxy: Connecting to api.oscar.aol.com:443.
    (14:09:54) proxy: Connected to api.oscar.aol.com:443.
    ..

and get the infamous error

    (14:18:07) oscar: startOSCARSession response statusCode was 401: <?xml version="1.0" encoding="UTF-8"?>
    <response xmlns="http://developer.aim.com/xsd/aim.xsd"><statusCode>401</statusCode><statusText>Authentication Required.  Connection not approved for 239.. .  Error code from BOSS 7.  statusDetailCode 7</statusText><statusDetailCode>7</statusDetailCode><data><ts>1310379488</ts><upgradeData></upgradeData><betaData></betaData></data></response>
    (14:18:07) connection: Connection error on 0x98b1e68 (reason: 16 description: You have been connecting and disconnecting too frequently. Wait ten minutes and try again. If you continue to try, you will need to wait even longer.)

From the aforementioned patch, seems like for SSL now i should use:

    --- libpurple/protocols/oscar/oscarcommon.h 0bc9985d11166bdfb5d992dae2a00784269e379e
    +++ libpurple/protocols/oscar/oscarcommon.h c0c1c79bb1873b915a8e9c90a4d103107d18d257
    ..
    +#define ICQ_DEFAULT_LOGIN_SERVER "login.icq.com"
    +#define ICQ_DEFAULT_SSL_LOGIN_SERVER "slogin.icq.com"
    ..

and for clientLogin (this is OpenAuth server address, right?
(AOL Developer Network/Authentication for Desktop Clients..)):

    --- libpurple/protocols/oscar/clientlogin.c f66d45ff55ef44bed415ddbd25e47f2d60c8d5ea
    +++ libpurple/protocols/oscar/clientlogin.c 6e0dab1b983a036019a31a3e89eeaf3f0284df21
    ..
    +#define AIM_LOGIN_HOST "api.screenname.aol.com"
    +#define ICQ_LOGIN_HOST "api.login.icq.net"

    +#define AIM_API_HOST "api.oscar.aol.com"
    +#define ICQ_API_HOST "api.icq.net"
    ..


I don't know how to fix server addresses for clientLogin without patching
source code, but, i think, i can simple fix SSL support - with stunnel.

Here is proposed way: pidgin will connect to 127.0.0.1:5190 and then stunnel
forwards its connection over SSL (terms correct?) to proper server
(slogin.icq.com:443).

pidgin config (in GUI Accounts/Manage Accounts -> Modify) should look like:

    server: 127.0.0.1
    port: 5190
    Unchecked "Use SSL"
    Unchecked "clientLogin"

and stunnel config:

    ; Protocol version (all, SSLv2, SSLv3, TLSv1)
    sslVersion = SSLv3

    chroot = /var/lib/stunnel4/
    setuid = stunnel4
    setgid = stunnel4
    ; PID is created inside the chroot jail
    pid = /stunnel4.pid

    ; Some performance tunings
    socket = l:TCP_NODELAY=1
    socket = r:TCP_NODELAY=1
    ;compression = zlib

    ; Some debugging stuff useful for troubleshooting
    debug = 7
    output = /var/log/stunnel4/stunnel.log

    ; Use it for client mode
    client = yes

    ; Service-level configuration
    [oscaricq]
    accept = 127.0.0.1:5190
    connect = slogin.icq.com:443

    ; vim:ft=dosini

There is also a small problem with stunnel - sometimes it can't resolve dns
name:

    2011.07.11 15:58:49 LOG7[4691:3075046256]: oscaricq permitted by libwrap from 127.0.0.1:53065
    2011.07.11 15:58:49 LOG5[4691:3075046256]: oscaricq accepted connection from 127.0.0.1:53065
    2011.07.11 15:58:49 LOG3[4691:3075046256]: Error resolving 'slogin.icq.com': Neither nodename nor servname known (EAI_NONAME)
    2011.07.11 15:58:49 LOG3[4691:3075046256]: No host resolved
    2011.07.11 15:58:49 LOG5[4691:3075046256]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket

Here

    (Jaervosz' Burrow): stunnel unable to resolve hostnames

suggested two possible fixes. I can either use 'delay = no' option in the
config (/etc/stunnel/stunnel.conf in debian squeeze) to tell stunnel to
resolve DNS names _before_ entering chroot, or i can use 'delay = yes' option
(see Note2 below) in the config (this is default for stunnel4, it seems) to
tell stunnel to resolve DNS names _after_ entering chroot and bind mount /etc
(or only required files - resolv.conf) into stunnel's chroot jail (note, that
without bind mount stunnel will not be able to resolve DNS names from inside
chroot).  Here is explanation from stunnel.org/FAQ:

    How can I delay DNS lookups until connect time?
      Add the following to your stunnel configuration file:

      delay = yes

And here is bind mount example:

    root@shilvana:~# touch /var/lib/stunnel4/etc/resolv.conf 
    root@shilvana:~# mount /etc/resolv.conf /var/lib/stunnel4/etc/resolv.conf  -o bind
    root@shilvana:~# /etc/init.d/stunnel4 restart

That's it, now enable account in pidgin and all should work.

Note1. Note, also, that if you use stunnel with 'delay = no' option and
stunnel starts very early when network is not available yet, than it can't
resolve DNS names, and you need to restart it later.

Note2: Note, that 'delay = yes' option must be in the service section of the
config file. Otherwise, it'll not work!
UPD4. 'Note2' note added.
UPD3. 'Note1' note added.
UPD2. Some additional clarifications about configuring stunnel to proper resolve DNS names.
UPD1. Update about configuring stunnel to proper resolve DNS names.

Комментариев нет:

Отправить комментарий