From lpkang139 at 139.com  Sun May  5 20:04:54 2013
From: lpkang139 at 139.com (lpkang139)
Date: Mon, 06 May 2013 08:04:54 +0800
Subject: No subject
Message-ID: <5186F3A6.90808@139.com>





From nmav at gnutls.org  Tue May  7 17:58:00 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 07 May 2013 23:58:00 +0200
Subject: ocserv 0.1.2
Message-ID: <518978E8.8080905@gnutls.org>

Hello,
 I've just released ocserv 0.1.2. ocserv is a VPN server that implements
the AnyConnect SSL VPN protocol and targets small embedded Linux devices.

This release fixes compilation issues in the *BSD family of systems
(though they may not be fully supported), and fixes all known
compatibility issues with the CISCO vpn client. More thorough testing
with that client to eliminate any other issues is encouraged.


The changes since 0.1.1 are:
- Several updates to allow compilation in FreeBSD.
- Allow prior to leasing an IP to ping it in order to check if it is in
  use.
- ocpasswd accepts options to lock and unlock users.
- Several updates to allow CISCO's anyconnect clients to connect to this
  server.


The current release is available at:
ftp://ftp.infradead.org/pub/ocserv/ocserv-0.1.2.tar.xz
ftp://ftp.infradead.org/pub/ocserv/ocserv-0.1.2.tar.xz.sig

The VPN server's web-site is at:
http://www.infradead.org/ocserv

regards,
Nikos


From James.Bottomley at HansenPartnership.com  Tue May  7 19:55:51 2013
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Tue, 07 May 2013 16:55:51 -0700
Subject: Problems maintaining openconnect VPN ... looks like MTU issue
Message-ID: <1367970951.4108.44.camel@dabdike>

I can establish an openconnect session just fine, but clicking on
certain internal websites or uploading files causes it to die.  The
message in the logs when it dies is:

2013-05-07T16:05:44.412857-07:00 dabdike openconnect[31278]: Attempting to connect to 199.115.105.249:443
2013-05-07T16:05:44.426232-07:00 dabdike openconnect[31278]: SSL negotiation with wavpn.sw.ru
2013-05-07T16:05:44.468655-07:00 dabdike openconnect[31278]: Connected to HTTPS on wavpn.sw.ru
2013-05-07T16:05:44.484071-07:00 dabdike openconnect[31278]: Got CONNECT response: HTTP/1.1 200 OK
2013-05-07T16:05:44.486165-07:00 dabdike openconnect[31278]: CSTP connected. DPD 30, Keepalive 20
2013-05-07T16:05:44.534758-07:00 dabdike openconnect[31278]: Connected vpn0 as 10.10.65.251, using SSL
2013-05-07T16:05:53.035643-07:00 dabdike openconnect[31278]: DTLS handshake failed: 2
2013-05-07T16:06:20.168218-07:00 dabdike openconnect[31278]: SSL wrote too few bytes! Asked for 654, sent 0
2013-05-07T16:06:20.171367-07:00 dabdike openconnect[31278]: Send BYE packet: Internal error
2013-05-07T16:06:20.172621-07:00 dabdike openconnect[31278]: SSL_write failed: 1
2013-05-07T16:06:20.173937-07:00 dabdike openconnect[31278]: 140673877575400:error:1409F07F:SSL routines:SSL3_WRITE_PENDING:bad write retry:s3_pkt.c:871:

The DTLS handshake failed looks like a red herring because that fills my
logs even if the connection is successful:

2013-05-07T16:17:13.001040-07:00 dabdike openconnect[31655]: DTLS handshake failed: 1
2013-05-07T16:17:13.032813-07:00 dabdike openconnect[31655]: 140411814278888:error:14102410:SSL routines:DTLS1_READ_BYTES:sslv3 alert handshake failure:d1_pkt.c:1166:SSL alert number 40

If I lower the MTU of vpn0 to 499 instead of the default 999, the
connection doesn't break nearly as frequently.

James




From dwmw2 at infradead.org  Wed May  8 02:24:05 2013
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 08 May 2013 07:24:05 +0100
Subject: Problems maintaining openconnect VPN ... looks like MTU issue
In-Reply-To: <1367970951.4108.44.camel@dabdike>
References: <1367970951.4108.44.camel@dabdike>
Message-ID: <1367994245.3378.32.camel@shinybook.infradead.org>

On Tue, 2013-05-07 at 16:55 -0700, James Bottomley wrote:
> 2013-05-07T16:06:20.168218-07:00 dabdike openconnect[31278]: SSL wrote too few bytes! Asked for 654, sent 0
> 2013-05-07T16:06:20.171367-07:00 dabdike openconnect[31278]: Send BYE packet: Internal error
> 2013-05-07T16:06:20.172621-07:00 dabdike openconnect[31278]: SSL_write failed: 1

That looks like the one I fixed in commit fddb099d?

> The DTLS handshake failed looks like a red herring because that fills my
> logs even if the connection is successful:

What version of OpenSSL (or GnuTLS) are you using for DTLS support? Some
recent versions of OpenSSL are known to be broken. If you build against
GnuTLS new enough to have Cisco DTLS support, that's best.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20130508/e043b69f/attachment.bin>

From James.Bottomley at HansenPartnership.com  Thu May  9 13:17:49 2013
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Thu, 09 May 2013 10:17:49 -0700
Subject: Problems maintaining openconnect VPN ... looks like MTU issue
In-Reply-To: <1367994245.3378.32.camel@shinybook.infradead.org>
References: <1367970951.4108.44.camel@dabdike>
 <1367994245.3378.32.camel@shinybook.infradead.org>
Message-ID: <1368119869.3276.47.camel@dabdike>

On Wed, 2013-05-08 at 07:24 +0100, David Woodhouse wrote:
> On Tue, 2013-05-07 at 16:55 -0700, James Bottomley wrote:
> > 2013-05-07T16:06:20.168218-07:00 dabdike openconnect[31278]: SSL wrote too few bytes! Asked for 654, sent 0
> > 2013-05-07T16:06:20.171367-07:00 dabdike openconnect[31278]: Send BYE packet: Internal error
> > 2013-05-07T16:06:20.172621-07:00 dabdike openconnect[31278]: SSL_write failed: 1
> 
> That looks like the one I fixed in commit fddb099d?

Um, yes.  openSUSE has a really old version of openconnect (3.99) after
redoing OBS to build me 4.08, the problem goes away.

> > The DTLS handshake failed looks like a red herring because that fills my
> > logs even if the connection is successful:
> 
> What version of OpenSSL (or GnuTLS) are you using for DTLS support? Some
> recent versions of OpenSSL are known to be broken. If you build against
> GnuTLS new enough to have Cisco DTLS support, that's best.

jejb at dabdike> ldd /usr/sbin/openconnect 
        linux-vdso.so.1 (0x00007fff23bb2000)
        libopenconnect.so.2 => /usr/lib64/libopenconnect.so.2
(0x00007f610fa22000)
        libssl.so.1.0.0 => /lib64/libssl.so.1.0.0 (0x00007f610f7b8000)
        libcrypto.so.1.0.0 => /lib64/libcrypto.so.1.0.0
(0x00007f610f3e5000)
        libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x00007f610f07e000)
        libproxy.so.1 => /usr/lib64/libproxy.so.1 (0x00007f610ee5b000)
        libz.so.1 => /lib64/libz.so.1 (0x00007f610ec45000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f610e898000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f610e694000)
        liblzma.so.5 => /usr/lib64/liblzma.so.5 (0x00007f610e46e000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f610e170000)
        libmodman.so.1 => /usr/lib64/libmodman.so.1 (0x00007f610df67000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f610dd4b000)
        libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f610da45000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f610d82f000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f610fc33000)
jejb at dabdike> rpm -qf /lib64/libssl.so.1.0.0
libopenssl1_0_0-1.0.1e-1.1.1.x86_64

James





From dwmw2 at infradead.org  Thu May  9 15:36:02 2013
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 09 May 2013 20:36:02 +0100
Subject: Problems maintaining openconnect VPN ... looks like MTU issue
In-Reply-To: <1368119869.3276.47.camel@dabdike>
References: <1367970951.4108.44.camel@dabdike>
 <1367994245.3378.32.camel@shinybook.infradead.org>
 <1368119869.3276.47.camel@dabdike>
Message-ID: <1368128162.10172.26.camel@i7.infradead.org>

On Thu, 2013-05-09 at 10:17 -0700, James Bottomley wrote:
> jejb at dabdike> rpm -qf /lib64/libssl.so.1.0.0
> libopenssl1_0_0-1.0.1e-1.1.1.x86_64

http://lists.infradead.org/pipermail/openconnect-devel/2013-February/000827.html ?

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20130509/5e044961/attachment.bin>

From christopherjmurphy at icloud.com  Tue May 14 14:32:45 2013
From: christopherjmurphy at icloud.com (Christopher Murphy)
Date: Tue, 14 May 2013 13:32:45 -0500
Subject: Prebuilt package for OS X 10.8.3
Message-ID: <D7F82509-E056-4A9B-9157-509DF122325F@icloud.com>

Dear sir/madam

Is there a downloadable prebuilt package for OS X 10.8.3.  I am new to the Mac OS X and have not been able to follow the compile instructions.

Many thanks

From dwmw2 at infradead.org  Wed May 15 16:32:17 2013
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 15 May 2013 21:32:17 +0100
Subject: OpenConnect 5.00 release
Message-ID: <1368649937.3490.16.camel@shinybook.infradead.org>

About time we finally released this... and also about time we switched
to building with GnuTLS by default instead of OpenSSL, so I did that
too. A few compatibility issues fixed, and makefiles for Android that
don't require the full AOSP build.

ftp://ftp.infradead.org/pub/openconnect/openconnect-5.00.tar.gz
ftp://ftp.infradead.org/pub/openconnect/openconnect-5.00.tar.gz.asc

Antonio Borneo (11):
      Uniform coding style: #if defined()
      Uniform coding style: space and tabs
      Uniform coding style: conditional statement
      Uniform coding style: no {} for single statement
      Uniform coding style: don't use C99 // comments
      gitignore: add autogen's files
      gitignore: add files from ./configure
      gitignore: add files from "make"
      gitignore: add cscope.*
      Add "-m" to getopt_long() parser
      Sort getopt_long optstring

David Woodhouse (48):
      Switch to using GnuTLS by default
      Document recent OpenSSL brokenness, update GnuTLS/DTLS info
      Add build time and run time handling of recent OpenSSL brokenness
      Don't print "DTLS connected" when it isn't yet
      Use gnutls_pubkey_verify_data2() where possible
      Merge retrospective 4.08 release into HEAD
      Fix GnuTLS 2.x build failure
      Fix abuse of realloc() causing memory leaks
      Fix abuse of gnutls_realloc() causing memory leaks
      Update changelog
      Link directly to Nikos' server web site
      Fix hostname canonicalisation to stop breaking certifcate checks
      Update translations from GNOME
      Fix Android build with NDK
      Don't attempt to parse empty response from server
      Handle redirects in attempting simple auth GET too
      Destroy vpninfo->https_cred on failing to create it
      Update translations from GNOME
      Use OPENSSL_CFLAGS when testing OpenSSL features too
      Make it easier to avoid the broken OpenSSL DTLS check
      Remove unused variable 'ofs' in Android keystore_fetch()
      Revamp Android build infrastructure
      Attempt to build GnuTLS for Android
      Use GNUTLS_CFLAGS when testing GnuTLS features too
      Avoid warning about verify_signed_data being unused
      Stop using deprecated gnutls_x509_crt type
      Android: Build GnuTLS from git
      Fix CSD trojan download
      Add missing newlines
      Reduce GnuTLS library size for Android build
      Import translations from GNOME
      Fix check for CSD
      CSD stub URL is optional
      Fix redirect to CSD stub URL
      Clean up CSD invocation for XML POST
      Fix Android builds for x86 and mips
      Enable shared libopenconnect for Android build
      Check for __ANDROID__ not ANDROID
      Import translations from GNOME
      Fix GMP configure rule for Android build
      Disable more GnuTLS bits
      Import translations from GNOME
      Import translations from GNOME
      Import translations from GNOME
      Import translations from GNOME
      Import translations from GNOME
      Import translations from GNOME
      Tag version 5.00

John Morrissey (2):
      Don't emit the login banner and/or message when -q is used
      Add TOTP (RFC6238) one-time password support

Kevin Cernekee (17):
      auth: Implement special handling of <select> dropdowns on XML POST
      auth: Implement special handling of password fields on XML POST
      http: Fix redirect handling in auth form loop
      auth: stoken: Fix handling of "Next TOKENCODE" prompt
      http: Don't leak the webvpn cookie in XML POST mode
      Add --without-libproxy and --without-stoken options to configure
      Tweak liboath ./configure help text for consistency
      Get rid of LIBSTOKEN_HDR and LIBOATH_HDR
      Fix token-related command line options
      Update man page and changelog to reflect --token-* changes
      Remove references to Android.mk
      Update comments to reflect library API changes
      android: Remove dependency on files outside the openconnect repo
      android: Hack around GnuTLS build breakage
      android: Override vpnc-script check in "configure"
      android: Add the correct toolchain directory to $PATH
      android: Run autogen.sh if configure script is missing

Nikos Mavrogiannopoulos (3):
      Fix arguments to gnutls_pubkey_verify_data2
      Add server page to web pages
      Check for __android_log_vprint in liblog.


-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20130515/09a9c31c/attachment.bin>

From sakutz at gmail.com  Wed May 15 16:45:51 2013
From: sakutz at gmail.com (Andrew Kutz)
Date: Wed, 15 May 2013 15:45:51 -0500
Subject: OpenConnect on OS X and the Latest AnyConnect SSL VPN Rev
Message-ID: <B9A0F05D-3B0F-48FD-B6D6-4820EABCC6F7@gmail.com>

David,

Thank you for this wonderful software. It's so nice to be able to create a VPN connection to my office without them totally raping my routing tables. That said, it took 48 hours of straight packet sniffing and mucking about to make it work. Here's how I got OpenConnect  4.08-4.99 to work against my company's AnyConnect SSL VPN solution from my OS X 10.8.2 client.

	? The 4.08 version available via Homebrew has an issue where the sfinst file is not downloaded, but rather the XML that points to it is. For example:

<?xml version="1.0" encoding="UTF-8"?>
<auth id="main" type="sdi">
    <title>SSL VPN Service</title>
    <ca href="/+CSCOCA+/login.html" status="disabled"/>
    <csd ticket="5E1380B54A1C94EC7CFF0B9F" token="24A9313E7D39FDF9276D6CC0"/>
    <csd preloginname="CSDPreLogin" preloginurl="/CACHE/sdesktop/install/binaries/cache.jar" starturl="/CACHE/sdesktop/install/result.htm" stuburl="/CACHE/sdesktop/install/binaries/inst.exe" waiturl="/+CSCOE+/sdesktop/wait.html"/>
    <csdMac starturl="/CACHE/sdesktop/install/result.htm" stuburl="/CACHE/sdesktop/install/binaries/sfinst" waiturl="/+CSCOE+/sdesktop/wait.html"/>
    <csdLinux starturl="/CACHE/sdesktop/install/result.htm" stuburl="/CACHE/sdesktop/install/binaries/sfinst" waiturl="/+CSCOE+/sdesktop/wait.html"/>
    <banner>This Virtual Private Network is intended for
authorized *** employees and contractors.
Unauthorized use is prohibited by law and may be
subject to civil and/or criminal penalties. This system
may be logged or monitored without further notice
and resulting logs may be used as evidence in court.</banner>
    <message>Please enter your username and password.</message>
    <form action="/+webvpn+/index.html" method="post">
        <input label="Username:" name="username" type="text"/>
        <input label="PASSCODE:" name="password" type="password"/>
        <input name="Login" type="submit" value="Login"/>
        <input name="Clear" type="reset" value="Clear"/>
    </form>
</auth>

	? Even when upgrading the Homebrew formula to 4.99, the issue persisted. It wasn't until I downloaded the 4.99 sources and compiled it outside of Homebrew that this issue went away. I have no idea why it did, but it did.

	? Which did not end up meaning a whole lot, because it turns out the current solution for CSD no longer works. This is the part that took 24 hours to figure out. It turns out that my company hasn't completely replaced the old method, but the above file is no longer used at all (although it is still retrieved and parsed by OpenConnect and the sfinst script is downloaded (once I compiled 4.99 from source) and executed. However, *every* time this happened a Java window would appear telling me that SwordFish.jar could not be found on the server. I thought it had to be because I was missing an auth header or something that the server wasn't letting me access the file. It worked fine in the browser?

	? After a day of playing around with various methods to figure out what was going on, I broke out the packet sniffers.

	? Even with stunnel providing a MITM proxy so I could decrypt the SSL, Wireshark was unable to reassemble the packets. Thus I loaded Fiddler on my Windows VM. I took three packet dumps using Fiddler's SSL decryption capabilities (it seamlessly sets up the same MITM configuration):
		? I connected to the VPN via the web inside the VM
		? I connected to the VPN via the web from my Mac (and used Fiddler's ability to advertise itself as a proxy to proxy my Mac's connections through that so I can dump those too)
		? I dumped OpenConnect

	? Now, I don't feel comfortable sharing the packet logs with the entire list, but I will send them directly to you. They include my company's IPs, and although they're discoverable, I'd rather not have them on a mailing list archive.

	? What I learned was that at least the version of AnyConnect to which I'm connecting no longer uses sfinst. It uses  /CACHE/sdesktop/install/binaries/instjava.java. 

	? I downloaded this file manually and using JD-GUI I tracked down how it's executed. It's very similar to the options used by sfinst:

(from InstallerJava.class)

   if (!OsIsWindows)
          {
            try
            {
              String str4 = "/bin/chmod u+x " + str2;
              localObject3 = ((Runtime)localObject1).exec(str4);
              int k = ((Process)localObject3).waitFor();
              if (k != 0) { log("chmod returned: " + k);
                setStatus(STATUS_STUB_FAILURE);
                setErrorCode(STUB_CHANGE_PERMISSION_FAILED);
                return;
              } } catch (Exception localException4) { log("Exception while giving executable permissions to stub");
              setStatus(STATUS_STUB_FAILURE);
              setErrorCode(STUB_CHANGE_PERMISSION_FAILED);
              log("Exception occured: " + localException4.getMessage());
              localException4.printStackTrace();
              return;
            }
          }
          ((Vector)localObject2).addElement(str2);
          if ((this.ticket.length() > 0) && (this.stub.length() > 0))
          {
            ((Vector)localObject2).addElement("-ticket");
            ((Vector)localObject2).addElement(this.ticket);
            ((Vector)localObject2).addElement("-stub");
            ((Vector)localObject2).addElement(this.stub);
          }
          if (this.certhash.length() > 0)
          {
            ((Vector)localObject2).addElement("-certhash");
            ((Vector)localObject2).addElement(this.certhash);
          }
          if (this.group.length() > 0)
          {

	? So it's executing some file. What file? Well, based on the packet dumps it's executing the file "/CACHE/sdesktop/hostscan/windows_i386/cstub.exe" on Windows and "/CACHE/sdesktop/hostscan/darwin_i386/cstub" on a Mac. I didn't test it on Linux.

	? At this point I could either patch the source of OpenConnect to make this work, or I could just use a CSD wrapper. I did the latter.

	? Also, FWIW, I did make one change to the sources for the sake of dumping the vpninfo easily to the logs:

diff --git a/auth.c b/auth.c
index c3bc4fb..7c06456 100644
--- a/auth.c
+++ b/auth.c
@@ -462,6 +462,15 @@ static int parse_auth_node(struct openconnect_info *vpninfo, xmlNode *xml_node,
                }
        }
 
+       /*vpn_progress(vpninfo, PRG_INFO,
+               _("vpninfo: tok=%s, tic=%s, stub=%s, start=%s, wait=%s"),
+               vpninfo->csd_token,
+               vpninfo->csd_ticket,
+               vpninfo->csd_stuburl,
+               vpninfo->csd_starturl,
+               vpninfo->csd_waiturl);*/
+       vpn_progress_all(vpninfo);
+
 out:
        return ret;
 }
diff --git a/openconnect-internal.h b/openconnect-internal.h
index 51172af..9f621b7 100644
--- a/openconnect-internal.h
+++ b/openconnect-internal.h
@@ -333,6 +333,13 @@ struct openconnect_info {
 #define AC_PKT_TERM_SERVER     9       /* Server kick */
 
 #define vpn_progress(vpninfo, ...) (vpninfo)->progress((vpninfo)->cbdata, __VA_ARGS__)
+#define vpninfo_string(vpninfo) _("vpninfo: tok='%s', tic='%s', stub='%s', start='%s', wait='%s'\n"),\
+    (vpninfo)->csd_token,\
+    (vpninfo)->csd_ticket,\
+    (vpninfo)->csd_stuburl,\
+    (vpninfo)->csd_starturl,\
+    (vpninfo)->csd_waiturl
+#define vpn_progress_all(vpninfo) vpn_progress((vpninfo), 1, vpninfo_string((vpninfo)))
 
 /****************************************************************************/
 /* Oh Solaris how we hate thee! */

	? So anyway, I fetched the cstub binary for Darwin and put it in $HOME/.vpn. I then wrote the following wrapper for it:

#!/bin/sh

echo "$0 $*"

shift

URL=
TICKET=
STUB=
GROUP=
CERTHASH=
LANGSELEN=

while [ "$1" ]; do
    if [ "$1" == "-ticket" ];   then shift; TICKET=$1; fi
    if [ "$1" == "-stub" ];     then shift; STUB=$1; fi
    if [ "$1" == "-group" ];    then shift; GROUPR=$1; fi
    if [ "$1" == "-certhash" ]; then shift; CERTHASH=$1; fi
    if [ "$1" == "-url" ];      then shift; URL=$1; fi
    if [ "$1" == "-langselen" ];then shift; LANGSELEN=$1; fi
    shift
done

echo "URL:          $URL"
echo "TICKET:       $TICKET"
echo "STUB:         $STUB"
echo "GROUP:        $GROUP"
echo "CERTHASH:     $CERTHASH"
echo "LANGSELEN:    $LANGSELEN"

ARGS="-url $URL -ticket $TICKET -stub $STUB"
if [ "$GROUP" ]; then ARGS="$ARGS -group $GROUP"; fi
ARGS="$ARGS -certhash $CERTHASH"
if [ "$LANGSELEN" ]; then ARGS="$ARGS -langsel $LANGSELEN"; fi

echo "Executing $HOME/.vpn/cstub $ARGS"
$HOME/.vpn/cstub $ARGS

	? Once that was in place OpenConnect was finally able to connect! Almost. There is a bug in your vpnc-script that you link to on your site. In the do_connect and do_disconnect methods an incorrect Bash comparison is used. The $NETWORK variable needs to be quoted:
			
			if [ "$NETWORK" != "0.0.0.0" ]; then
				set_network_route "$NETWORK" "$NETMASK" "$NETMASKLEN"
			else
				set_default_route
			fi

After I did all that I was finally able to connect to my VPN as well as split-tunnel my connection using the CISCO_SPLIT_INC_%d_\w+ variables. Thank you so much for this awesome piece of software!

The packet dumps are here - https://docs.google.com/file/d/0BwA1o-dOr0AVbE1Wd0VYdF9zNjQ/edit?usp=sharing. I will be sending you the password for the 7z in a separate, private e-mail.

-- 
-a

"I wonder if procrastinators realize that they're not putting off work, just putting it off onto other people?"

From paravoid at debian.org  Thu May 16 09:18:00 2013
From: paravoid at debian.org (Faidon Liambotis)
Date: Thu, 16 May 2013 16:18:00 +0300
Subject: ocserv: http parsing flaw results in disabled DTLS
Message-ID: <20130516131800.GA11086@tty.gr>

Hi,

[ not subscribed to the list, Cc me on replies please ]

I'm trying ocserv 0.1.2 in combination with Debian wheezy's openconnect 
(3.20). It looks like there is a bug in the way ocserv uses the 
http-parser library that results in misparsing the HTTP headers and 
X-DTLS-Master-Secret specifically, which in turn results in DTLS being 
disabled.

More specifically, ocserv reads from the socket and feeds the buffer to 
http-parser as it goes, with http-parser potentially trying to parse 
partial header fields/values.

X-DTLS-Master-Secret is being received one byte at a time, which results 
in lines like:
ocserv[30247]: [2001:(...)]:43911 HTTP: X-DTLS-Master-Secret: 54
ocserv[30247]: [2001:(...)]:43911 HTTP: X-DTLS-Master-Secret: D7
ocserv[30247]: [2001:(...)]:43911 HTTP: X-DTLS-Master-Secret: 7F
ocserv[30247]: [2001:(...)]:43911 HTTP: X-DTLS-Master-Secret: 62
and ocserv takes no special provisions on concatenating all those 
values;  it just compares their length (1) to TLS_MASTER_SIZE*2 and if 
it's smaller, outright rejects the key.

This is not X-DTLS-Master-Secret / DTLS specific at all, but rather a 
flaw on how the http-parser API is being used by ocserv in general. It 
just happened due to openconnect client's implementation to hit this in 
X-DTLS-Master-Secret values but it could have happened in other header 
values or even field names.

The misuse of the API is actually documented on http-parser's 
documentation[1]: "Reading headers may be a tricky task if you 
read/parse headers partially. Basically, you need to remember whether 
last header callback was field or value and apply following logic [...] 
Value continues. Reallocate value buffer and append callback data to 
it".

I could give a stab at a fix, although it looks like it would be fairly 
invasive on the HTTP handling codepath so I figured you might want to 
redesign this yourself :)

Cheers,
Faidon

1: https://github.com/joyent/http-parser


From paravoid at debian.org  Thu May 16 10:16:35 2013
From: paravoid at debian.org (Faidon Liambotis)
Date: Thu, 16 May 2013 17:16:35 +0300
Subject: [PATCH 1/2] Workaround libseccomp bug & fix error handling
Message-ID: <1368713796-14388-1-git-send-email-paravoid@debian.org>

libseccomp has a bug where -EDOM is returned when seccomp_rule_add is
called for pseudo system calls (i.e. < -99). This was triggered by
adding the send() system call on my x86_64 machine. The bug seems to
have been recently (May 7th, 2013) reported and fixed on libseccomp
upstream but it will take a while to find its way to a release and
distributions.

Additionally, there was a bug on how libseccomp calls were error
handled: libseccomp functions don't actually set errno, but set errno
values in their return value instead. This resulted in the
seccomp_rule_add call above to print "could not add send to seccomp
filter: Success".
---
 src/worker-privs.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/worker-privs.c b/src/worker-privs.c
index 4794525..2b3158d 100644
--- a/src/worker-privs.c
+++ b/src/worker-privs.c
@@ -26,7 +26,7 @@
 
 int disable_system_calls(struct worker_st *ws)
 {
-	int ret, e;
+	int ret;
 	scmp_filter_ctx ctx;
 	
 	ctx = seccomp_init(SCMP_ACT_KILL);
@@ -37,9 +37,9 @@ int disable_system_calls(struct worker_st *ws)
 
 #define ADD_SYSCALL(name) \
 	ret = seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(name), 0); \
-	if (ret < 0) { \
-		e = errno; \
-		oclog(ws, LOG_WARNING, "could not add " #name " to seccomp filter: %s", strerror(e)); \
+	/* libseccomp returns EDOM for pseudo-syscalls due to a bug */ \
+	if (ret < 0 && ret != -EDOM) { \
+		oclog(ws, LOG_WARNING, "could not add " #name " to seccomp filter: %s", strerror(-ret)); \
 		ret = -1; \
 		goto fail; \
 	}
-- 
1.7.2.5



From paravoid at debian.org  Thu May 16 10:16:36 2013
From: paravoid at debian.org (Faidon Liambotis)
Date: Thu, 16 May 2013 17:16:36 +0300
Subject: [PATCH 2/2] Make seccomp failures non-fatal & lower log prio
In-Reply-To: <1368713796-14388-1-git-send-email-paravoid@debian.org>
References: <1368713796-14388-1-git-send-email-paravoid@debian.org>
Message-ID: <1368713796-14388-2-git-send-email-paravoid@debian.org>

Building a binary with --enable-seccomp and then running it on a < 3.5
kernel, results in seccomp_load() failing and ocserv's worker process
aborting. This might be okay-ish for users who ./configure && make
install on their own systems but it's obviously non-ideal for e.g.
distributions that need to distribute binaries.

Unfortunately there doesn't seem to be a good way (that I could find) to
check if the running kernel has seccomp -- uname/uts isn't a good
solution as Ubuntu has backported it to 3.2, custom kernels might have
CONFIG_SECCOMP=n etc.

So, this makes a tradeoff call and removes the exit_worker() call on
seccomp failures, lowers the seccomp error logs to LOG_DEBUG from
LOG_WARNING and the "could not disable system calls" to LOG_INFO from
LOG_ERR.
---
 src/worker-privs.c |    6 +++---
 src/worker-vpn.c   |    3 +--
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/src/worker-privs.c b/src/worker-privs.c
index 2b3158d..95b49dc 100644
--- a/src/worker-privs.c
+++ b/src/worker-privs.c
@@ -31,7 +31,7 @@ int disable_system_calls(struct worker_st *ws)
 	
 	ctx = seccomp_init(SCMP_ACT_KILL);
 	if (ctx == NULL) {
-		oclog(ws, LOG_WARNING, "could not initialize seccomp");
+		oclog(ws, LOG_DEBUG, "could not initialize seccomp");
 		return -1;
 	}
 
@@ -39,7 +39,7 @@ int disable_system_calls(struct worker_st *ws)
 	ret = seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(name), 0); \
 	/* libseccomp returns EDOM for pseudo-syscalls due to a bug */ \
 	if (ret < 0 && ret != -EDOM) { \
-		oclog(ws, LOG_WARNING, "could not add " #name " to seccomp filter: %s", strerror(-ret)); \
+		oclog(ws, LOG_DEBUG, "could not add " #name " to seccomp filter: %s", strerror(-ret)); \
 		ret = -1; \
 		goto fail; \
 	}
@@ -66,7 +66,7 @@ int disable_system_calls(struct worker_st *ws)
 
 	ret = seccomp_load(ctx);
 	if (ret < 0) {
-		oclog(ws, LOG_ERR, "could not load seccomp filter");
+		oclog(ws, LOG_DEBUG, "could not load seccomp filter");
 		ret = -1;
 		goto fail;
 	}
diff --git a/src/worker-vpn.c b/src/worker-vpn.c
index 3ff612e..d573320 100644
--- a/src/worker-vpn.c
+++ b/src/worker-vpn.c
@@ -490,8 +490,7 @@ void vpn_server(struct worker_st* ws)
 		
 	ret = disable_system_calls(ws);
 	if (ret < 0) {
-		oclog(ws, LOG_ERR, "could not disable system calls (seccomp error)");
-		exit_worker(ws);
+		oclog(ws, LOG_INFO, "could not disable system calls, kernel might not support seccomp");
 	}
 
 	oclog(ws, LOG_INFO, "accepted connection");
-- 
1.7.2.5



From nmav at gnutls.org  Thu May 16 17:06:35 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 16 May 2013 23:06:35 +0200
Subject: ocserv: http parsing flaw results in disabled DTLS
In-Reply-To: <20130516131800.GA11086@tty.gr>
References: <20130516131800.GA11086@tty.gr>
Message-ID: <20130516230635.79182696@aspire.lan>

On Thu, 16 May 2013 16:18:00 +0300
Faidon Liambotis <paravoid at debian.org> wrote:

> Hi,
> [ not subscribed to the list, Cc me on replies please ]
> I'm trying ocserv 0.1.2 in combination with Debian wheezy's
> openconnect (3.20). It looks like there is a bug in the way ocserv
> uses the http-parser library that results in misparsing the HTTP
> headers and X-DTLS-Master-Secret specifically, which in turn results
> in DTLS being disabled.
> More specifically, ocserv reads from the socket and feeds the buffer
> to http-parser as it goes, with http-parser potentially trying to
> parse partial header fields/values.

Hello Faidon,
 I think I have received this bug report before, but it seems I never
solved it. By looking at it, it is quite some work to rewrite that
part. I'll try to check it as soon.

regards,
Nikos


From nmav at gnutls.org  Thu May 16 17:07:24 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 16 May 2013 23:07:24 +0200
Subject: [PATCH 1/2] Workaround libseccomp bug & fix error handling
In-Reply-To: <1368713796-14388-1-git-send-email-paravoid@debian.org>
References: <1368713796-14388-1-git-send-email-paravoid@debian.org>
Message-ID: <20130516230724.7d26d8fe@aspire.lan>

On Thu, 16 May 2013 17:16:35 +0300
Faidon Liambotis <paravoid at debian.org> wrote:

> libseccomp has a bug where -EDOM is returned when seccomp_rule_add is
> called for pseudo system calls (i.e. < -99). This was triggered by
> adding the send() system call on my x86_64 machine. The bug seems to
> have been recently (May 7th, 2013) reported and fixed on libseccomp
> upstream but it will take a while to find its way to a release and
> distributions.

Both patches applied.

regards,
Nikos


From martin.uhrin at gmail.com  Mon May 20 05:42:18 2013
From: martin.uhrin at gmail.com (Martin Uhrin)
Date: Mon, 20 May 2013 10:42:18 +0100
Subject: Problems connecting to VPN that insists on downloading secure desktop
Message-ID: <CAOpmb4T=ksJbJ7hS-fKf4AQVS9NEvLWkh8542QJFGFHOWDtGPg@mail.gmail.com>

Dear Openconnect community,

I'm trying to connect to our Uni VPN which I haven't done with
openconnect before so I have no idea if I can expect it to work.

The latest failure I get is 'Failed to exec CSD script
/tmp/csdq9y1Q8'.  I realise that I can supply a custom script but what
would this have to contain?

Would someone be able to see if they can get past this stage of
communicating with our server?

Many thanks,
-Martin

OS: Ubuntu 64 13.04

Full output:

./openconnect -v vpn.ucl.ac.uk --csd-user=[my username]
Attempting to connect to server 128.40.125.50:443
SSL negotiation with vpn.ucl.ac.uk
Matched DNS altname 'vpn.ucl.ac.uk'
Connected to HTTPS on vpn.ucl.ac.uk
POST https://vpn.ucl.ac.uk/
Got HTTP response: HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Cache-Control: no-cache
Pragma: no-cache
Connection: Keep-Alive
Date: Mon, 20 May 2013 09:34:25 GMT
X-Aggregate-Auth: 1
HTTP body chunked (-2)
XML POST enabled
GET https://vpn.ucl.ac.uk/+CSCOE+/sdesktop/wait.html
Failed to exec CSD script /tmp/csdq9y1Q8
Got HTTP response: HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Cache-Control: no-cache
Pragma: no-cache
Connection: Close
Date: Mon, 20 May 2013 09:34:25 GMT
HTTP body chunked (-2)
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...

(This just repeats ad-infinitum).


From cernekee at gmail.com  Mon May 20 11:45:46 2013
From: cernekee at gmail.com (Kevin Cernekee)
Date: Mon, 20 May 2013 08:45:46 -0700
Subject: Problems connecting to VPN that insists on downloading secure
 desktop
In-Reply-To: <CAOpmb4T=ksJbJ7hS-fKf4AQVS9NEvLWkh8542QJFGFHOWDtGPg@mail.gmail.com>
References: <CAOpmb4T=ksJbJ7hS-fKf4AQVS9NEvLWkh8542QJFGFHOWDtGPg@mail.gmail.com>
Message-ID: <CAJiQ=7CiCyBhSbfcu8ZTrfrJ5SJDbHSp3Q7_2W87Hmd3QXVUrQ@mail.gmail.com>

On Mon, May 20, 2013 at 2:42 AM, Martin Uhrin <martin.uhrin at gmail.com> wrote:
> I'm trying to connect to our Uni VPN which I haven't done with
> openconnect before so I have no idea if I can expect it to work.
>
> The latest failure I get is 'Failed to exec CSD script
> /tmp/csdq9y1Q8'.  I realise that I can supply a custom script but what
> would this have to contain?

The older server installations would provide a standalone CSD binary
that openconnect could execute in its own process, but unfortunately
this method seems to be deprecated by Cisco.  On this server the Linux
legacy CSD binary does not appear to be installed at all:

curl -I --insecure
https://vpn.ucl.ac.uk/CACHE/sdesktop/install/binaries/sfinst -> 404
Not Found

On a known good server:

curl -I --insecure
https://vpn.mobile.unibas.ch/CACHE/sdesktop/install/binaries/sfinst ->
301 redirect to an installation script

FWIW the legacy Windows binary is installed:

curl -I --insecure
https://vpn.ucl.ac.uk/CACHE/sdesktop/install/binaries/inst.exe -> 200
OK

But that doesn't help us.  So, you may want to sniff a good AnyConnect
session and write a --csd-wrapper script that posts the appropriate
data to the server.

> POST https://vpn.ucl.ac.uk/
> Got HTTP response: HTTP/1.1 200 OK
> Content-Type: text/html; charset=UTF-8
> Transfer-Encoding: chunked
> Cache-Control: no-cache
> Pragma: no-cache
> Connection: Keep-Alive
> Date: Mon, 20 May 2013 09:34:25 GMT
> X-Aggregate-Auth: 1
> HTTP body chunked (-2)
> XML POST enabled
> GET https://vpn.ucl.ac.uk/+CSCOE+/sdesktop/wait.html
> Failed to exec CSD script /tmp/csdq9y1Q8

One of the side effects of using the new "XML POST" protocol is that
the server response will not provide the paths to the legacy CSD
binaries, even if the binaries are present.  This means that it is
mandatory to use --csd-wrapper instead of --csd-user.

I would be curious to know whether the legacy CSD binaries ever work
properly with the newer servers.  I have seen at least one case where
they were present but completely non-functional.


From mkitchin.public at gmail.com  Thu May 23 17:43:20 2013
From: mkitchin.public at gmail.com (Matthew Kitchin (Public/Usenet))
Date: Thu, 23 May 2013 16:43:20 -0500
Subject: Compatibility with 2 factor authentication?
Message-ID: <519E8D78.9000202@gmail.com>

We are migrating to a Duo Security product for secondary authentication 
on our ASA. This prompts another box to show up in the Windows GUI 
client labeled 'Second Password'. Does openconnect have the ability to 
interact with this second password dialog? I found this: 
http://lists.infradead.org/pipermail/openconnect-devel/2010-September/000226.html 
and it appears to be the same thing, but I'm unclear on what the 
resolution was. I"m using command line only on an openwrt router.


From cernekee at gmail.com  Thu May 23 20:27:52 2013
From: cernekee at gmail.com (Kevin Cernekee)
Date: Thu, 23 May 2013 17:27:52 -0700
Subject: Compatibility with 2 factor authentication?
In-Reply-To: <519E8D78.9000202@gmail.com>
References: <519E8D78.9000202@gmail.com>
Message-ID: <CAJiQ=7BE7FyDYqFakUgPr88HX1LSOYPFOtiLh3Jr3U5wUbFj+Q@mail.gmail.com>

On Thu, May 23, 2013 at 2:43 PM, Matthew Kitchin (Public/Usenet)
<mkitchin.public at gmail.com> wrote:
> We are migrating to a Duo Security product for secondary authentication on
> our ASA. This prompts another box to show up in the Windows GUI client
> labeled 'Second Password'. Does openconnect have the ability to interact
> with this second password dialog? I found this:
> http://lists.infradead.org/pipermail/openconnect-devel/2010-September/000226.html
> and it appears to be the same thing, but I'm unclear on what the resolution
> was. I"m using command line only on an openwrt router.

When I configured my dummy gateway to serve up the auth form in your
link, the openconnect CLI prompted for both passwords and seemed to do
the right thing:

<?xml version="1.0" encoding="UTF-8"?>
<config-auth client="vpn" type="auth-reply">
  <version who="vpn">v5.00-3-gf81acba-dirty</version>
  <device-id>linux-64</device-id>
  <auth>
    <username>user</username>
    <password>1stpass</password>
    <secondary_password>2ndpass</secondary_password>
    <tgroup>SII-PRIV</tgroup>
  </auth>
</config-auth>

The official AnyConnect clients do implement a couple of special cases
on password fields with certain names[1]; we might also need to add a
check for the "second-auth" attribute.  This could account for why the
Windows client changes the label from "Password:" to "Second
Password:".

[1] http://git.infradead.org/users/dwmw2/openconnect.git/commit/e8a0cecc6ddcfffd4663d359f17ebba195cb4d69


From dwmw2 at infradead.org  Fri May 24 16:04:16 2013
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 24 May 2013 21:04:16 +0100
Subject: Compatibility with 2 factor authentication?
In-Reply-To: <519E8D78.9000202@gmail.com>
References: <519E8D78.9000202@gmail.com>
Message-ID: <1369425856.27719.37.camel@shinybook.infradead.org>

On Thu, 2013-05-23 at 16:43 -0500, Matthew Kitchin (Public/Usenet)
wrote:
> We are migrating to a Duo Security product for secondary authentication 
> on our ASA. This prompts another box to show up in the Windows GUI 
> client labeled 'Second Password'. Does openconnect have the ability to 
> interact with this second password dialog? I found this: 
> http://lists.infradead.org/pipermail/openconnect-devel/2010-September/000226.html 
> and it appears to be the same thing, but I'm unclear on what the 
> resolution was. I"m using command line only on an openwrt router.

It should work fine. Each form that the server offers should be
presented directly to the user. The integration with openwrt's luci
configuration system is somewhat limited, and assumes a single username
and password. But that can be fixed too, if you want to do things
"properly" on the openwrt box.

-- 
dwmw2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20130524/28f2af2e/attachment.bin>

From alikilani at mail.com  Mon May 27 16:30:26 2013
From: alikilani at mail.com (Ali Al-Kilani)
Date: Mon, 27 May 2013 22:30:26 +0200
Subject: Assalamalaikum
Message-ID: <bOu1RUQs3Udbp7DLn0n4UCpoW23sjugHfmvT9TmpjRuV@mail.com>

I am Ali Al-Kilani a descendant and citizen of Libyan Arab People's Republic. I have an issue that need a little assistance should you be willing you can make as much as half a million dollars.
Regards
Ali



From mkitchin.public at gmail.com  Tue May 28 09:56:05 2013
From: mkitchin.public at gmail.com (Matthew Kitchin (Public/Usenet))
Date: Tue, 28 May 2013 08:56:05 -0500
Subject: Compatibility with 2 factor authentication?
In-Reply-To: <1369425856.27719.37.camel@shinybook.infradead.org>
References: <519E8D78.9000202@gmail.com>
 <1369425856.27719.37.camel@shinybook.infradead.org>
Message-ID: <51A4B775.5070202@gmail.com>

On 5/24/2013 3:04 PM, David Woodhouse wrote:
> On Thu, 2013-05-23 at 16:43 -0500, Matthew Kitchin (Public/Usenet)
> wrote:
>> We are migrating to a Duo Security product for secondary authentication
>> on our ASA. This prompts another box to show up in the Windows GUI
>> client labeled 'Second Password'. Does openconnect have the ability to
>> interact with this second password dialog? I found this:
>> http://lists.infradead.org/pipermail/openconnect-devel/2010-September/000226.html
>> and it appears to be the same thing, but I'm unclear on what the
>> resolution was. I"m using command line only on an openwrt router.
> It should work fine. Each form that the server offers should be
> presented directly to the user. The integration with openwrt's luci
> configuration system is somewhat limited, and assumes a single username
> and password. But that can be fixed too, if you want to do things
> "properly" on the openwrt box.
>
Luci is the web interface, isn't it? I'm just using the command line. At 
the moment, it does not seem to be popping up the second password dialog.


From dwmw2 at infradead.org  Tue May 28 10:22:30 2013
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 28 May 2013 15:22:30 +0100
Subject: Compatibility with 2 factor authentication?
In-Reply-To: <51A4B775.5070202@gmail.com>
References: <519E8D78.9000202@gmail.com>
 <1369425856.27719.37.camel@shinybook.infradead.org>
 <51A4B775.5070202@gmail.com>
Message-ID: <1369750950.4711.1.camel@i7.infradead.org>

On Tue, 2013-05-28 at 08:56 -0500, Matthew Kitchin (Public/Usenet) wrote:
> Luci is the web interface, isn't it? I'm just using the command line. At 
> the moment, it does not seem to be popping up the second password dialog.

Show (in private if you prefer) the 'openconnect -v' output please.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20130528/321301f9/attachment.bin>

From mkitchin.public at gmail.com  Tue May 28 13:43:59 2013
From: mkitchin.public at gmail.com (Matthew Kitchin (Public/Usenet))
Date: Tue, 28 May 2013 12:43:59 -0500
Subject: Compatibility with 2 factor authentication?
In-Reply-To: <1369750950.4711.1.camel@i7.infradead.org>
References: <519E8D78.9000202@gmail.com>	
 <1369425856.27719.37.camel@shinybook.infradead.org>	
 <51A4B775.5070202@gmail.com> <1369750950.4711.1.camel@i7.infradead.org>
Message-ID: <51A4ECDF.3000808@gmail.com>

On 5/28/2013 9:22 AM, David Woodhouse wrote:
> On Tue, 2013-05-28 at 08:56 -0500, Matthew Kitchin (Public/Usenet) wrote:
>> Luci is the web interface, isn't it? I'm just using the command line. At
>> the moment, it does not seem to be popping up the second password dialog.
> Show (in private if you prefer) the 'openconnect -v' output please.
>
It is old. It looks like it is the latest available in the Openwrt 
repository. The last time I tried to compile a newer version, I failed 
miserably. I believe you ended up doing it for me.

root at OpenWrt:~# openconnect -v
No server specified
Usage:  openconnect [options] <server>
Open client for Cisco AnyConnect VPN, version v2.25-unknown



From celpa.firl at gmail.com  Wed May 29 05:41:44 2013
From: celpa.firl at gmail.com (ed bond)
Date: Wed, 29 May 2013 04:41:44 -0500
Subject: Openconnect 4 and 5 doesn't want to connect to my ssl vpn.
Message-ID: <7F88EED7-E509-45CE-BA6B-BFC7A236BE59@gmail.com>

I am trying to connect to my work vpn via open connect.

If I try to connect without the CSD the error is as follows:

Error: Server asked us to download and run a 'Cisco Secure Desktop' trojan.
This facility is disabled by default for security reasons, so you may wish to enable it.
Failed to obtain WebVPN cookie


If I try to connect with getting the shell to work properly and passing a wrapper, it loads a jnlp and doesn't properly execute.

ebond:vpn ebond$ sudo openconnect --csd-wrapper=asdf.sh --csd-user=root --user=bonde --cafile=/Users/ebond/work/vpn/rsa.pem vpn-usa-west.NOTREAL.COM
Attempting to connect to server 137.69.122.5:443
SSL negotiation with vpn-usa-west.NOTREAL.COM
Connected to HTTPS on vpn-usa-west.NOTREAL.COM
POST https://vpn-usa-west.NOTREAL.COM/
Got HTTP response: HTTP/1.0 302 Temporary moved
Attempting to connect to server 137.69.122.7:443
SSL negotiation with scl02-01i11-vn04.NOTREAL.COM
Connected to HTTPS on scl02-01i11-vn04.NOTREAL.COM
POST https://scl02-01i11-vn04.NOTREAL.COM/
Got HTTP response: HTTP/1.0 302 Object Moved
SSL negotiation with scl02-01i11-vn04.NOTREAL.COM
Connected to HTTPS on scl02-01i11-vn04.NOTREAL.COM
GET https://scl02-01i11-vn04.NOTREAL.COM/+webvpn+/index.html
GET https://scl02-01i11-vn04.NOTREAL.COM/CACHE/sdesktop/install/binaries/sfinst
Trying to run Linux CSD trojan script.
GET https://scl02-01i11-vn04.NOTREAL.COM/+CSCOE+/sdesktop/wait.html
Params
/tmp/csdvpwe38 -ticket "3AE4DA8B75D2785A5205C005" -stub "0" -group "" -certhash "9CE3B7DC697B5FDAA01538E4ECA4B741:" -url "https://scl02-01i11-vn04.NOTREAL.COM/CACHE/sdesktop/install/result.htm" -langselen
working with: -url
"https://scl02-01i11-vn04.NOTREAL.COM/CACHE/sdesktop/install/result.htm"
ok cool trying this
https://scl02-01i11-vn04.NOTREAL.COM/+CSCOE+/sdesktop/webstart.xml?ticket="3AE4DA8B75D2785A5205C005"&stub="0"&group=""&certhash="9CE3B7DC697B5FDAA01538E4ECA4B741:"&langselen=&noCC=1
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
SSL negotiation with scl02-01i11-vn04.NOTREAL.COM
Connected to HTTPS on scl02-01i11-vn04.NOTREAL.COM
GET https://scl02-01i11-vn04.NOTREAL.COM/+CSCOE+/sdesktop/wait.html
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
/usr/bin/javaws https://scl02-01i11-vn04.NOTREAL.COM/+CSCOE+/sdesktop/webstart.xml?ticket="3AE4DA8B75D2785A5205C005"&stub="0"&group=""&certhash="9CE3B7DC697B5FDAA01538E4ECA4B741:"&langselen=&noCC=1
SSL negotiation with scl02-01i11-vn04.NOTREAL.COM
Connected to HTTPS on scl02-01i11-vn04.NOTREAL.COM
GET https://scl02-01i11-vn04.NOTREAL.COM/+CSCOE+/sdesktop/wait.html
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
SSL negotiation with scl02-01i11-vn04.NOTREAL.COM
#### Java Web Start Error:
#### Unable to load resource: https://scl02-01i11-vn04.NOTREAL.COM/CACHE/sdesktop/install/binaries/extensions/SwordFish.jar
Connected to HTTPS on scl02-01i11-vn04.NOTREAL.COM
GET https://scl02-01i11-vn04.NOTREAL.COM/+CSCOE+/sdesktop/wait.html
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...

I have the issue with the following versions:

OpenConnect version v5.00
Using OpenSSL. Features present: TPM (OpenSSL ENGINE not present), DTLS

OpenConnect version v4.07
Using GnuTLS. Features present: PKCS#11, DTLS (using OpenSSL)


If I load the web page from safari it works. If I connect via the any connect client it works as well.


I can capture the https traffic via a Man in the middle attack as well. I am just having issues generating a CSD wrapper that properly does what is needed that automatically happens for the website. Anyone have any pointers?

- Firl



From cernekee at gmail.com  Wed May 29 14:26:22 2013
From: cernekee at gmail.com (Kevin Cernekee)
Date: Wed, 29 May 2013 11:26:22 -0700
Subject: Openconnect 4 and 5 doesn't want to connect to my ssl vpn.
In-Reply-To: <7F88EED7-E509-45CE-BA6B-BFC7A236BE59@gmail.com>
References: <7F88EED7-E509-45CE-BA6B-BFC7A236BE59@gmail.com>
Message-ID: <CAJiQ=7AKFc6iHd23G40fL6W+6xFp1-=ggS8QB=7u-BXivOGkSQ@mail.gmail.com>

On Wed, May 29, 2013 at 2:41 AM, ed bond <celpa.firl at gmail.com> wrote:
> I can capture the https traffic via a Man in the middle attack as well. I am just having issues generating a CSD wrapper that properly does what is needed that automatically happens for the website. Anyone have any pointers?

I think one of your co-workers posted an OSX wrapper script (and a
bunch of details on how he did it) a few weeks back.  Might be a good
starting point at least.


From dwmw2 at infradead.org  Wed May 29 18:05:51 2013
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 29 May 2013 23:05:51 +0100
Subject: Compatibility with 2 factor authentication?
In-Reply-To: <51A4ECDF.3000808@gmail.com>
References: <519E8D78.9000202@gmail.com>
 <1369425856.27719.37.camel@shinybook.infradead.org>
 <51A4B775.5070202@gmail.com> <1369750950.4711.1.camel@i7.infradead.org>
 <51A4ECDF.3000808@gmail.com>
Message-ID: <1369865151.20691.28.camel@shinybook.infradead.org>

On Tue, 2013-05-28 at 12:43 -0500, Matthew Kitchin (Public/Usenet)
wrote:
> On 5/28/2013 9:22 AM, David Woodhouse wrote:
> > On Tue, 2013-05-28 at 08:56 -0500, Matthew Kitchin (Public/Usenet) wrote:
> >> Luci is the web interface, isn't it? I'm just using the command line. At
> >> the moment, it does not seem to be popping up the second password dialog.
> > Show (in private if you prefer) the 'openconnect -v' output please.
> >
> It is old. It looks like it is the latest available in the Openwrt 
> repository.

The AA release should have 4.08.

-- 
dwmw2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20130529/9e2bfb8b/attachment.bin>

From mkitchin.public at gmail.com  Wed May 29 23:01:18 2013
From: mkitchin.public at gmail.com (Matthew Kitchin (Public/Usenet))
Date: Wed, 29 May 2013 22:01:18 -0500
Subject: Compatibility with 2 factor authentication?
In-Reply-To: <1369865151.20691.28.camel@shinybook.infradead.org>
References: <519E8D78.9000202@gmail.com>		
 <1369425856.27719.37.camel@shinybook.infradead.org>		
 <51A4B775.5070202@gmail.com> <1369750950.4711.1.camel@i7.infradead.org>	
 <51A4ECDF.3000808@gmail.com>
 <1369865151.20691.28.camel@shinybook.infradead.org>
Message-ID: <51A6C0FE.5020606@gmail.com>

On 5/29/2013 5:05 PM, David Woodhouse wrote:
> The AA release should have 4.08.
I see. I checked every now and then, but I had not yet noticed that AA 
had hit a stable release. I will upgrade this weekend.


From dwmw2 at infradead.org  Thu May 30 05:25:11 2013
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 30 May 2013 10:25:11 +0100
Subject: Compatibility with 2 factor authentication?
In-Reply-To: <51A6C0FE.5020606@gmail.com>
References: <519E8D78.9000202@gmail.com>
 <1369425856.27719.37.camel@shinybook.infradead.org>
 <51A4B775.5070202@gmail.com> <1369750950.4711.1.camel@i7.infradead.org>
 <51A4ECDF.3000808@gmail.com>
 <1369865151.20691.28.camel@shinybook.infradead.org>
 <51A6C0FE.5020606@gmail.com>
Message-ID: <1369905911.20691.51.camel@shinybook.infradead.org>

On Wed, 2013-05-29 at 22:01 -0500, Matthew Kitchin (Public/Usenet) wrote:
> On 5/29/2013 5:05 PM, David Woodhouse wrote:
> > The AA release should have 4.08.
> I see. I checked every now and then, but I had not yet noticed that AA 
> had hit a stable release. I will upgrade this weekend.

You could try updating just openconnect, perhaps? Although you might
need a newer OpenSSL for that...

-- 
dwmw2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20130530/5a278605/attachment.bin>

From larrymp at yahoo.com  Thu May 30 11:29:36 2013
From: larrymp at yahoo.com (Larry Phillips)
Date: Thu, 30 May 2013 08:29:36 -0700 (PDT)
Subject: ocserv 0.1.2 anyconnect client expects client download
Message-ID: <1369927776.57801.YahooMailNeo@web161004.mail.bf1.yahoo.com>

oc linux client works fine, cisco anyconnect client win/mac expects client download and can't seem to bypass with xml profile. ?Local login auth works then see gets from client for /1/<client-os> and client exits with error "The AnyConnect package on the secure gateway could not be located. ?You may be experiencing network connectivity issues. ?Please try connecting again."

debug below for win client, osx looks similar

?ocserv -f --debug -c /usr/local/etc/ocserv.conflistening (TCP) on [0.0.0.0]:443...
listening (UDP) on [0.0.0.0]:443...
ocserv[31881]: sec-mod initialized (socket: /var/run/ocserv-socket.31880)
ocserv[31883]: [97.104.220.70]:54157 accepted connection
ocserv[31883]: GnuTLS error (at worker-vpn.c:526): The TLS connection was non-properly terminated.
ocserv[31884]: [97.104.220.70]:54158 accepted connection
ocserv[31884]: [97.104.220.70]:54158 TLS handshake completed
ocserv[31884]: [97.104.220.70]:54158 HTTP: Cache-Control: no-cache
ocserv[31884]: [97.104.220.70]:54158 HTTP: Connection: close
ocserv[31884]: [97.104.220.70]:54158 HTTP: Pragma: no-cache
ocserv[31884]: [97.104.220.70]:54158 HTTP: User-Agent: AnyConnect Windows 3.0.4235
ocserv[31884]: [97.104.220.70]:54158 HTTP: X-Transcend-Version: 1
ocserv[31884]: [97.104.220.70]:54158 HTTP: X-Aggregate-Auth: 1
ocserv[31884]: [97.104.220.70]:54158 HTTP: X-AnyConnect-Platform: win
ocserv[31884]: [97.104.220.70]:54158 HTTP: Content-Length: 209
ocserv[31884]: [97.104.220.70]:54158 HTTP: Host: x.x.x.x
ocserv[31884]: [97.104.220.70]:54158 HTTP POST /
ocserv[31884]: [97.104.220.70]:54158 POST body: '<?xml version="1.0" encoding="UTF-8"?>
<config-auth client="vpn" type="init">
<device-id>win</device-id>
<version who="vpn">3.0.4235</version>
<group-access>https://x.x.x.x</group-access>
</config-auth>
'
ocserv[31885]: [97.104.220.70]:54159 accepted connection
ocserv[31885]: [97.104.220.70]:54159 sending resumption request (fetch)
ocserv[31885]: [97.104.220.70]:54159 TLS handshake completed
ocserv[31885]: [97.104.220.70]:54159 HTTP: Cache-Control: no-cache
ocserv[31885]: [97.104.220.70]:54159 HTTP: Connection: Close
ocserv[31885]: [97.104.220.70]:54159 HTTP: Pragma: no-cache
ocserv[31885]: [97.104.220.70]:54159 HTTP: User-Agent: AnyConnect Windows 3.0.4235
ocserv[31885]: [97.104.220.70]:54159 HTTP: X-Transcend-Version: 1
ocserv[31885]: [97.104.220.70]:54159 HTTP: X-Aggregate-Auth: 1
ocserv[31885]: [97.104.220.70]:54159 HTTP: X-AnyConnect-Platform: win
ocserv[31885]: [97.104.220.70]:54159 HTTP: Content-Length: 30
ocserv[31885]: [97.104.220.70]:54159 HTTP: Host: x.x.x.x
ocserv[31885]: [97.104.220.70]:54159 HTTP POST /auth
ocserv[31885]: [97.104.220.70]:54159 sending authentication request
ocserv[31880]: [main] assigning tun device vpns0
ocserv[31880]: [97.104.220.70]:54159 user 'iopdric' of group 'ocserv-profile' authenticated
ocserv[31885]: [97.104.220.70]:54159 User 'iopdric' logged in
ocserv[31914]: [97.104.220.70]:54160 accepted connection
ocserv[31914]: [97.104.220.70]:54160 sending resumption request (fetch)
ocserv[31914]: [97.104.220.70]:54160 TLS handshake completed
ocserv[31914]: [97.104.220.70]:54160 HTTP: Cache-Control: no-cache
ocserv[31914]: [97.104.220.70]:54160 HTTP: Connection: Close
ocserv[31914]: [97.104.220.70]:54160 HTTP: Pragma: no-cache
ocserv[31914]: [97.104.220.70]:54160 HTTP: Cookie: webvpn=********;
ocserv[31914]: [97.104.220.70]:54160 HTTP: User-Agent: AnyConnect Windows 3.0.4235
ocserv[31914]: [97.104.220.70]:54160 HTTP: X-Transcend-Version: 1
ocserv[31914]: [97.104.220.70]:54160 HTTP: X-Aggregate-Auth: 1
ocserv[31914]: [97.104.220.70]:54160 HTTP: X-AnyConnect-Platform: win
ocserv[31914]: [97.104.220.70]:54160 HTTP: Host: x.x.x.x
ocserv[31914]: [97.104.220.70]:54160 HTTP GET /1/index.html
ocserv[31915]: [97.104.220.70]:54161 accepted connection
ocserv[31915]: [97.104.220.70]:54161 sending resumption request (fetch)
ocserv[31915]: [97.104.220.70]:54161 TLS handshake completed
ocserv[31915]: [97.104.220.70]:54161 HTTP: Cache-Control: no-cache
ocserv[31915]: [97.104.220.70]:54161 HTTP: Connection: Close
ocserv[31915]: [97.104.220.70]:54161 HTTP: Pragma: no-cache
ocserv[31915]: [97.104.220.70]:54161 HTTP: Cookie: webvpn=********
ocserv[31915]: [97.104.220.70]:54161 HTTP: User-Agent: AnyConnect Windows 3.0.4235
ocserv[31915]: [97.104.220.70]:54161 HTTP: X-Transcend-Version: 1
ocserv[31915]: [97.104.220.70]:54161 HTTP: X-Aggregate-Auth: 1
ocserv[31915]: [97.104.220.70]:54161 HTTP: X-AnyConnect-Platform: win
ocserv[31915]: [97.104.220.70]:54161 HTTP: Host: x.x.x.x
ocserv[31915]: [97.104.220.70]:54161 HTTP GET /1/Windows
ocserv[31915]: [97.104.220.70]:54161 unexpected URL /1/Windows
ocserv[31916]: [97.104.220.70]:54162 accepted connection
ocserv[31916]: [97.104.220.70]:54162 sending resumption request (fetch)
ocserv[31916]: [97.104.220.70]:54162 TLS handshake completed
ocserv[31916]: [97.104.220.70]:54162 HTTP: Cache-Control: no-cache
ocserv[31916]: [97.104.220.70]:54162 HTTP: Connection: Close
ocserv[31916]: [97.104.220.70]:54162 HTTP: Pragma: no-cache
ocserv[31916]: [97.104.220.70]:54162 HTTP: Cookie: webvpn=********
ocserv[31916]: [97.104.220.70]:54162 HTTP: User-Agent: AnyConnect Windows 3.0.4235
ocserv[31916]: [97.104.220.70]:54162 HTTP: X-Transcend-Version: 1
ocserv[31916]: [97.104.220.70]:54162 HTTP: X-Aggregate-Auth: 1
ocserv[31916]: [97.104.220.70]:54162 HTTP: X-AnyConnect-Platform: win
ocserv[31916]: [97.104.220.70]:54162 HTTP: Host: x.x.x.x
ocserv[31916]: [97.104.220.70]:54162 HTTP GET /2/index.html
ocserv[31916]: [97.104.220.70]:54162 unexpected URL /2/index.html
ocserv[31917]: [97.104.220.70]:54163 accepted connection
ocserv[31917]: [97.104.220.70]:54163 sending resumption request (fetch)
ocserv[31917]: [97.104.220.70]:54163 TLS handshake completed
ocserv[31917]: [97.104.220.70]:54163 HTTP: Cache-Control: no-cache
ocserv[31917]: [97.104.220.70]:54163 HTTP: Connection: Close
ocserv[31917]: [97.104.220.70]:54163 HTTP: Pragma: no-cache
ocserv[31917]: [97.104.220.70]:54163 HTTP: Cookie: webvpn=********
ocserv[31917]: [97.104.220.70]:54163 HTTP: User-Agent: AnyConnect Windows 3.0.4235
ocserv[31917]: [97.104.220.70]:54163 HTTP: X-Transcend-Version: 1
ocserv[31917]: [97.104.220.70]:54163 HTTP: X-Aggregate-Auth: 1
ocserv[31917]: [97.104.220.70]:54163 HTTP: X-AnyConnect-Platform: win
ocserv[31917]: [97.104.220.70]:54163 HTTP: Host: x.x.x.x
ocserv[31917]: [97.104.220.70]:54163 HTTP GET /1/index.html
ocserv[31918]: [97.104.220.70]:54164 accepted connection
ocserv[31918]: [97.104.220.70]:54164 sending resumption request (fetch)
ocserv[31918]: [97.104.220.70]:54164 TLS handshake completed
ocserv[31918]: [97.104.220.70]:54164 HTTP: Cache-Control: no-cache
ocserv[31918]: [97.104.220.70]:54164 HTTP: Connection: Close
ocserv[31918]: [97.104.220.70]:54164 HTTP: Pragma: no-cache
ocserv[31918]: [97.104.220.70]:54164 HTTP: Cookie: webvpn=********
ocserv[31918]: [97.104.220.70]:54164 HTTP: User-Agent: AnyConnect Windows 3.0.4235
ocserv[31918]: [97.104.220.70]:54164 HTTP: X-Transcend-Version: 1
ocserv[31918]: [97.104.220.70]:54164 HTTP: X-Aggregate-Auth: 1
ocserv[31918]: [97.104.220.70]:54164 HTTP: X-AnyConnect-Platform: win
ocserv[31918]: [97.104.220.70]:54164 HTTP: Host: x.x.x.x
ocserv[31918]: [97.104.220.70]:54164 HTTP GET /1/Windows
ocserv[31918]: [97.104.220.70]:54164 unexpected URL /1/Windows
ocserv[31920]: [97.104.220.70]:54165 accepted connection
ocserv[31920]: [97.104.220.70]:54165 sending resumption request (fetch)
ocserv[31920]: [97.104.220.70]:54165 TLS handshake completed
ocserv[31920]: [97.104.220.70]:54165 HTTP: Cache-Control: no-cache
ocserv[31920]: [97.104.220.70]:54165 HTTP: Connection: Close
ocserv[31920]: [97.104.220.70]:54165 HTTP: Pragma: no-cache
ocserv[31920]: [97.104.220.70]:54165 HTTP: Cookie: webvpn=********
ocserv[31920]: [97.104.220.70]:54165 HTTP: User-Agent: AnyConnect Windows 3.0.4235
ocserv[31920]: [97.104.220.70]:54165 HTTP: X-Transcend-Version: 1
ocserv[31920]: [97.104.220.70]:54165 HTTP: X-Aggregate-Auth: 1
ocserv[31920]: [97.104.220.70]:54165 HTTP: X-AnyConnect-Platform: win
ocserv[31920]: [97.104.220.70]:54165 HTTP: Host: x.x.x.x
ocserv[31920]: [97.104.220.70]:54165 HTTP GET /2/index.html
ocserv[31920]: [97.104.220.70]:54165 unexpected URL /2/index.html
ocserv[31921]: [97.104.220.70]:54178 accepted connection
ocserv[31921]: [97.104.220.70]:54178 sending resumption request (fetch)
ocserv[31921]: [97.104.220.70]:54178 TLS handshake completed
ocserv[31921]: [97.104.220.70]:54178 HTTP: Cache-Control: no-cache
ocserv[31921]: [97.104.220.70]:54178 HTTP: Connection: Close
ocserv[31921]: [97.104.220.70]:54178 HTTP: Pragma: no-cache
ocserv[31921]: [97.104.220.70]:54178 HTTP: Cookie: webvpn=********
ocserv[31921]: [97.104.220.70]:54178 HTTP: User-Agent: AnyConnect Windows 3.0.4235
ocserv[31921]: [97.104.220.70]:54178 HTTP: X-Transcend-Version: 1
ocserv[31921]: [97.104.220.70]:54178 HTTP: X-Aggregate-Auth: 1
ocserv[31921]: [97.104.220.70]:54178 HTTP: X-AnyConnect-Platform: win
ocserv[31921]: [97.104.220.70]:54178 HTTP: Host: x.x.x.x
ocserv[31921]: [97.104.220.70]:54178 HTTP GET //logout


From mkitchin.public at gmail.com  Thu May 30 13:58:15 2013
From: mkitchin.public at gmail.com (Matthew Kitchin (Public/Usenet))
Date: Thu, 30 May 2013 12:58:15 -0500
Subject: Compatibility with 2 factor authentication?
In-Reply-To: <1369905911.20691.51.camel@shinybook.infradead.org>
References: <519E8D78.9000202@gmail.com>			
 <1369425856.27719.37.camel@shinybook.infradead.org>			
 <51A4B775.5070202@gmail.com> <1369750950.4711.1.camel@i7.infradead.org>		
 <51A4ECDF.3000808@gmail.com>	
 <1369865151.20691.28.camel@shinybook.infradead.org>	
 <51A6C0FE.5020606@gmail.com>
 <1369905911.20691.51.camel@shinybook.infradead.org>
Message-ID: <51A79337.9010302@gmail.com>

On 5/30/2013 4:25 AM, David Woodhouse wrote:
> You could try updating just openconnect, perhaps? Although you might
> need a newer OpenSSL for that...
I think it would have to be compiled and I seem to lack the skills to do 
that. I wanted to upgrade my router anyway. I went ahead and did the 
upgrade last night to Attitude Adjustment with the option to 'keep 
settings'. It semi bricked it, but I have it about 50% back to life with 
stock Buffalo WZR-HP-G300NH firmware. I will try to get AA loaded on it 
tonight and see how it goes.


From n.mavrogiannopoulos at gmail.com  Fri May 31 04:19:29 2013
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Fri, 31 May 2013 10:19:29 +0200
Subject: ocserv 0.1.2 anyconnect client expects client download
In-Reply-To: <1369927776.57801.YahooMailNeo@web161004.mail.bf1.yahoo.com>
References: <1369927776.57801.YahooMailNeo@web161004.mail.bf1.yahoo.com>
Message-ID: <CAJU7zaJrCv2udjCTKJM8s7o28jeKycmBwtBASMvGo3d8tFqntw@mail.gmail.com>

On Thu, May 30, 2013 at 5:29 PM, Larry Phillips <larrymp at yahoo.com> wrote:
> oc linux client works fine, cisco anyconnect client win/mac expects client download and can't seem to bypass with xml profile.  Local login auth works then see gets from client for /1/<client-os> and client exits with error "The AnyConnect package on the secure gateway could not be located.  You may be experiencing network connectivity issues.  Please try connecting again."
> debug below for win client, osx looks similar
>  ocserv -f --debug -c /usr/local/etc/ocserv.conflistening (TCP) on [0.0.0.0]:443...
[...]
> ocserv[31915]: [97.104.220.70]:54161 HTTP GET /1/Windows
> ocserv[31915]: [97.104.220.70]:54161 unexpected URL /1/Windows

Hello,
 Indeed the cisco clients fail if they cannot open that directory (or
binary). The way I solved that was by adding
<BypassDownloader>true</BypassDownloader>
to the client configuration xml.

regards,
Nikos


From dwmw2 at infradead.org  Fri May 31 10:00:32 2013
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 31 May 2013 15:00:32 +0100
Subject: gnutls ca store for opensuse 12.1
In-Reply-To: <20130428121144.GA14721@rhrk.uni-kl.de>
References: <20130428121144.GA14721@rhrk.uni-kl.de>
Message-ID: <1370008832.5141.91.camel@i7.infradead.org>

On Sun, 2013-04-28 at 14:11 +0200, Joerg Mayer wrote:
> Hello,
> 
> this is against git head from today.

Apologies for delayed reply. Some messages which came in while I was on
paternity leave got ignored a little bit... :)

> During configure:
> 
> checking for GNUTLS... yes
> checking for gnutls_dtls_set_data_mtu... no
> checking for gnutls_certificate_set_x509_system_trust... no
> checking For location of system CA trust file... NOT FOUND
> configure: error: Unable to find a standard system CA certificate file.
>     Your GnuTLS requires a path to a CA certificate store. This is a file
>     which contains a list of the Certificate Authorities which are trusted.

It looks like upstream GnuTLS will fail similarly, right? I've
added /etc/ssl/ca-bundle.pem to my list, as you suggest. Nikos will
presumably want to do the same?

http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/d5381b38


> diff --git a/configure.ac b/configure.ac
> a/configure.ac
> +    AC_CHECK_FUNC(gnutls_pk_to_sign,
> +                [AC_DEFINE(HAVE_GNUTLS_PUBKEY_TO_SIGN, 1)], [])
>      AC_CHECK_FUNC(gnutls_pubkey_verify_data2,
>                  [AC_DEFINE(HAVE_GNUTLS_PUBKEY_VERIFY_DATA2, 1)], [])
> diff --git a/gnutls.c b/gnutls.c
> --- a/gnutls.c
> -#ifdef HAVE_GNUTLS_PUBKEY_VERIFY_DATA2
> +#if defined(HAVE_GNUTLS_PUBKEY_VERIFY_DATA2) && defined(HAVE_GNUTLS_PUBKEY_TO_SIGN)
>         gnutls_sign_algorithm_t algo = GNUTLS_SIGN_RSA_SHA1; /* TPM keys */

In fact we might as well not bother checking for
gnutls_pubkey_verify_data2() at all. We'll check *only* for
gnutls_pk_to_sign(). If that doesn't exist, then we'll just use
gnutls_pubkey_verify_data() as before.

http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/221948f8

> Doing make now gets me a bit further:
> 
>   CC     openconnect-dtls.o
> ../dtls.c:129:2: error: #error This version of OpenSSL is known to be broken with Cisco DTLS.
>  #error This version of OpenSSL is known to be broken with Cisco DTLS.
>   ^
> make[1]: *** [openconnect-dtls.o] Error 1
> 
> IMO, this is plain wrong for several reasons:

Yeah, I was being lazy and pushing the burden onto the people who are
still using OpenSSL when they should have switched to GnuTLS (which is
in fact the default now, since 5.00).

http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/a899e355

Thanks for reporting these.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20130531/b5248f6c/attachment.bin>

