Re: [Openvpn-devel] Character classes in the tls-verify script
On 2009.11.12 at 19:25:16 +0100, David Sommerseth wrote: > > no-name-remapping has side effects, i.e. disables system method of > > script execution. > > I'd have to disagree here. OpenVPN should not change the default > behaviour at all, as that can break a lot of already implemented > installations if the default remapping goes away. And forcing values to > stay inside the 7bit ASCII region is most likely the expected behaviour > as well. I doubt so. If you don't believe me, ask someone whose native language is French or German and who has characters with umlauts in his name - does he like this character to be replaced with underscore. Even for Western Europe restricting character set of certificates to 7-bit is the source of problem, not to mention rest of world, where any name would be replaced by string of underscores. If someone want to limit characters allowed in the certificates, it should be done on the CA level, not when parsing certificates. On this level only reason to map characters is to prevent common mistakes in the shell script. Characters outside of ASCII range never can be misinterpreted by shells, so they should be allowed. > > Really, I think than name remapping shouldn't be applied to environment > > variables at all. May be for command line arguments should be protected > > this way. But people who use environment variables typically are clever > > enough to handle shell special characters. > > I am willing to agree with you to some extent here, but OpenVPN cannot > change the current default behaviour of remapping. This would have to > be thought of when this feature was initially implemented in OpenVPN, > now it is too late to change the defaults. It is possible to add ADDITIONAL configuration directive such as --allow-unicode-in-names, which doesn't have such side-effect as no-name-remapping does now. But I think that this should be enabled by default. If someone cannot handle normal letters, he can disable them. > Unfortunately, not many thinks about characters outside the standard > 7bit ASCII. I've even experienced developers who got non-ASCII Just all Russia, all Japan and all China. We just got too tired of persuading english speaking developers, that world is somewhat bigger than Northern America and often prefer to fork and maintain our own localized version of software.
Re: [Openvpn-devel] Character classes in the tls-verify script
On 2009.11.12 at 10:01:55 -0700, James Yonan wrote: > Victor Wagner wrote: > > On 2009.10.24 at 13:39:56 -0600, James Yonan wrote: > > > >> Can you submit a patch (as an email attachment) with this fix? > > Attached > > > > This patch also contains X509_NAME_oneline replacement, which handles > > MSB characters. > > > > I've not checked if this patch applies cleanly to unmodified source. > > I've just diffed original 2.1_rc19 source, imported in our subversion > > repository with current working copy and removed all irrelevant chunks. > > Thanks for putting this together. > > I'm a bit concerned about changing any of the remapping behavior unless > no-name-remapping is specified. I see that in some areas, you test the > no-name-remapping flag before you modify existing behavior, but in other > areas such as my_X509_NAME_oneline, X509_NAME_CHAR_CLASS, and > COMMON_NAME_CHAR_CLASS you don't. Problem is that existing behavoir seems to be designed without non-ascii alphabets in mind. I think that "preserving existing behavoir" is "exporting alpabetic characters as they are". Since it is quite hard to distinguish between "alphabetic" and "non-alphabetic" outside of ASCII range, and no shell use non-ascii as separators (which is primary reason of remapping), I've considered safe way to treat all 8-bit characters as alphabetic. no-name-remapping has side effects, i.e. disables system method of script execution. So, all non-latin-writting users would face choice - either use their native language and loose some functionality of openvpn or have full fuctionality and loose native languge. Really, I think than name remapping shouldn't be applied to environment variables at all. May be for command line arguments should be protected this way. But people who use environment variables typically are clever enough to handle shell special characters. Moreover, if script is written in some better language than shell (i.e. perl, tcl on even is a C program, which should be probably considered worse language, as it is prone of buffer overflows), or for dlopened plugin same remapping rules are applied.
Re: [Openvpn-devel] Script interface to trigger events depending on the validity of a certificate
On 2009.11.11 at 16:04:12 +0100, David Sommerseth wrote: > I completely agree, that under normal circumstances, it should be enough > by letting OpenSSL take care of the certificate chain. But as OpenVPN > now do list more certificates already, I was just trying to keep that > possibility still open. > > In the OpenVPN plug-in I've written which does username, password and > certificate authentication, I've been playing with an idea of using the > certificate chain to apply different "rules" (network, login hours, etc) > based on the certificate chain as well. I think it is what certificate policies are for (see RFC 5280). Unfortinately policy support is very poorly documented in the OpenSSL (although some documentation for certificate chain verification was added in 1.0.0 beta 4 and it is applicable to early versions as well) So my patch for policy checking allows only to specify several policies to accept. It doesn't pass that policy which was found in the certificate after all policy mappings found in CA certificates were applied to scripts/plugins. There are also attribute certificates which can be used for such autorization purposes as well.
Re: [Openvpn-devel] Script interface to trigger events depending on the validity of a certificate
On 2009.11.11 at 13:00:05 +0100, David Sommerseth wrote: > > Good point! I was not aware of the Apache/mod_ssl way of doing it. My > only concern about that is if it would be possible to exhaust the memory > pool for environment variables? Imagine a a buffer overflow bug if an > attacker sends a specially crafted certificate request with 1000 > certificates in a chain. I'm not sure that all intermediate CA Certificates have to be exported such way. I don't remember if Apache does so, because I never tried to test Apache with chain longer than 1 and without intermediate CA certs in the OpenSSL cert-store. For most purposes two things are sufficient 1. Check validity of client certificate data using chain (i.e. did intermediate CAs have right to issue certificate with such extension). It is better done inside OpenSSL. I've written patch which enables OpenSSL builtin certificate policy checking in OpenVPN. 2. Get an information from client certificate, not from intermediate CA certificate in the chain. > The reason for this concern is that OpenVPN provides now all certificate > info available at once in many of the the different hooks, all with _0, > _1, _2, etc as a suffix at the end of the environment variable name. > With roughly 2KB per certificate, on a cruel attack with 1000 chained > certificates, that could mean 2MB would be needed for the environment > table and you would have 1000 environment variables to go through. [skip] > One way how to control this situation would be to also implement a > "--max-chained-certs" argument, which would default at something > reasonable, f.ex 5. > Really, OpenSSL allows to set maximal verification depth. Apache mod_ssl has a configuration directive which sets maximum allowed chain length using SSL_CTX_set_verify_depth function. OpenVPN doesn't provide such a directive now. So, may be exporting certificate should be accompanied with providing such a directive with reasonable default. I've never seen chains longer than 3, so 5 should be sufficient.
Re: [Openvpn-devel] Script interface to trigger events depending on the validity of a certificate
On 2009.11.11 at 09:40:59 +0100, David Sommerseth wrote: > On 10/11/09 17:16, Till Maas wrote: > > I would like to get a notification in case a client certificate is used > > for a connection to an OpenVPN server, that is about to expire soon. Is > > there currently a way to do this? I looked into the tls-verify hook, but > > according to the documentation, only the Subject line of a certificate > > is available and not the validity. Is there maybe a way to log the > > expiration dates? > > I don't think this is possible without patching openvpn to put these > values into some environment variables for the --tls-verify hook. I've > done something similar in regards to the SHA1 fingerprint for my own > project (I have had an OpenVPN patch pending since RC7). But I'd be > willing to carry such a feature in my eurephia patch for OpenVPN, as > that sounds very useful. Apache/mod_ssl does export entire certificate in the PEM format as environment variable. So, may be openvpn sould do the same? Now various people patching openvpn to add some values: you've added sha1 fingerprint, I've added certificate extension subjectAltName, et cetera, et cetera. But if entire certificate would be available, it would be possible to extract any information from it (or hash it with any algorithm) from the script using openssl command line utility or some binding or OpenSSL libraries to the choosen script language.
Re: [Openvpn-devel] [Openvpn-users] OpenVPN and OpenSSL TLS issue ? (CVE-2009-3555)
On 2009.11.08 at 12:59:47 +0100, David Sommerseth wrote: > > This flaw makes it, how I have understood it, possible to "duplicate" an > on-going SSL connection (or transaction, which it often is referred to), > making the SSL based server believe those two connections are the same > client. > The MITM attacker sends a SSL/TLS protocol renegotiation request to the > server, the server responds to it back to the attacker, where the > attacker and the server agrees on a new transaction protocol. Then the > attacker sends this server response back to the original client, and the > client continues as before. > I also understand it that the attacker cannot read the traffic from the > client, but the attacker now got an accepted channel which the server > now recognises equally as the client channel. So it is kind of like a > hidden hijack of an on-going connection. No. It only makes it possible to send few packetes which server would misinterpret as coming from legitimate client. Once real ClientHelo message from legitimate client is send, and renegotiation takes place, attacker can't neither read nor send any information to the server. Problem is that HTTPS server typically don't care whether information was send before renegotiation or after. It assembles both information into one HTTP request and executes it. Attack is only applicable to the situation where same server accepts both non-authenticated and authenticated connections on the same port, and allows clients to upgrade connection from non-authenticated to authenticated. I'm not sure that this behavoir is not possible at all with OpenVPN, but I've never seen such a configuration. Either client certificates are required (so MitM cannot perform first handshake) or are not required at all. With HTTPS it is also possible to hijack connection with basic auth (i.e with username/password send via TLS=encrypted channel) using this renegotiation mechanism. But only because action is send as first line of HTTP-request and WWW-Authenticate header - later. For any protocol which requires client to authenticate itself before sending commands, this attack is not applicable. This is why this flaw go unnoticed for so many years.
Re: [Openvpn-devel] [Openvpn-users] OpenVPN and OpenSSL TLS issue ? (CVE-2009-3555)
On 2009.11.08 at 00:17:38 +0100, David Sommerseth wrote: > > Well said! Thank you for emphasising this. In my earlier posts, I > never intended to suggest that this was a work around, just to be clear > about that. But --tls-auth is now, how I see it, the only way currently > available "immediately" (vs. waiting for openssl to be widely available > on all distros) which can make you safer against the current SSL/TLS flaw. Can anybody explain, how the "current SSL/TLS flaw" can be used to exploit OpenVPN. As far as I can understand this flaw is ability to upgrade secure connection from non-authenticated to authenticated transparently to application layer. If then application applies security context of the upgraded connection retroactively to the data send by non-authenticated client before upgrading, exploit is possible. This is typical behavoir of HTTP servers, which allows https connection without client authentication, and then request renegotiation based on URL send by encrypted, but not-authenticated connection, and if proper client certificate is supplied - perform request send before authentication. Moreover, attacker cannot even read result of this request, because it is send over upgraded coonection. So, it is not really applicable to any connection-based protocols which maintain state. Only stateless HTTPS is vulnerable. I cannot imagine even IMAP exploit, because IMAP severely limits set of commands, available in the pre-auth state. But OpenVPN uses TLS for authentication and key negotiation only. So, non-authenticated man-in-the-middle attacker cannot send any commands which would be executed after attacker hand connection over to legitimate client.
[Openvpn-devel] OpenVPN and modern cryptography
Now openvpn in tls-server mode requires specification of Diffie-Hellman parameters for ephemeral key. This is probably good thing for SSLv3 when only RSA and DSA ciphersuites are supported. DSA ciphersuites always require DH parameters, and RSA ciphersuites without DHE key exchange do not provide perfect forward secrecy. But with release of OpenSSL 1.0.0 lot of new ciphersuites based on elliptic curve algorithms (ECDSA, ECDH, GOST2001) become available. These ciphersuites do not need dh paramters, but ECDSA ciphersuites need ECDH parameters (typically, just curve name). GOST2001 do not need parameters - its parameter sets are hardcoded into RFC 4357 and draft for GOST tls specifes that same parameter set as used for server certificate should be used for ephemeral keys. So, for people which use these ciphersuites only, dh parameters are not nessessary (but curve name might be nesseccary, and there is no option for it in the OpenVPN 2.1 rc19). I've developed patch which changed handling of dh configuration directive. Check for notnull(dh_file) is removed, but check for list of available ciphersuites is added. If after applying tls-cipher argument any of ciphersuites with key exchange algorithm DH is left in the context's list of ciphersuites, openvpn complains about missing dh parameters. This patch can be easily extended for checking for ECDH ciphersuites and paramters as well. Is anybody interested in this functionality?
Re: [Openvpn-devel] Character classes in the tls-verify script
On 2009.10.24 at 13:39:56 -0600, James Yonan wrote:
>
> Can you submit a patch (as an email attachment) with this fix?
Attached
This patch also contains X509_NAME_oneline replacement, which handles
MSB characters.
I've not checked if this patch applies cleanly to unmodified source.
I've just diffed original 2.1_rc19 source, imported in our subversion
repository with current working copy and removed all irrelevant chunks.
Index: ssl.c
===
--- ssl.c (.../tags/openvpn-2.1_rc19) (revision 4645)
+++ ssl.c (.../trunk/openvpn-2.1_rc19) (revision 4645)
@@ -435,8 +435,8 @@
name_expand = (char *) malloc (name_expand_size);
check_malloc_return (name_expand);
openvpn_snprintf (name_expand, name_expand_size, "X509_%d_%s", error_depth, objbuf);
- string_mod (name_expand, CC_PRINT, CC_CRLF, '_');
- string_mod ((char*)buf, CC_PRINT, CC_CRLF, '_');
+ string_mod (name_expand, CC_PRINT|CC_MSB, CC_CRLF, '_');
+ string_mod ((char*)buf, CC_PRINT|CC_MSB, CC_CRLF, '_');
setenv_str (es, name_expand, (char*)buf);
free (name_expand);
OPENSSL_free (buf);
@@ -584,11 +584,24 @@
string_mod_sslname (char *str, const unsigned int restrictive_flags, const unsigned int ssl_flags)
{
if (ssl_flags & SSLF_NO_NAME_REMAPPING)
-string_mod (str, CC_PRINT, CC_CRLF, '_');
+string_mod (str, CC_PRINT|CC_MSB, CC_CRLF, '_');
else
string_mod (str, restrictive_flags, 0, '_');
}
+static char *my_X509_NAME_oneline(X509_NAME *name) {
+ BIO *b = BIO_new(BIO_s_mem());
+ long datalen;
+ char *p,*q;
+ X509_NAME_print_ex(b, name, 0, (XN_FLAG_ONELINE | ASN1_STRFLGS_UTF8_CONVERT) & ~ASN1_STRFLGS_ESC_MSB);
+ datalen = BIO_get_mem_data(b,&p);
+ q=OPENSSL_malloc(datalen+1);
+ strncpy(q,p,datalen);
+ q[datalen]=0;
+ BIO_free(b);
+ return q;
+}
+
/*
* Our verify callback function -- check
* that an incoming peer certificate is good.
@@ -617,7 +630,7 @@
session->verified = false;
/* get the X509 name */
- subject = X509_NAME_oneline (X509_get_subject_name (ctx->current_cert), NULL, 0);
+ subject = my_X509_NAME_oneline (X509_get_subject_name (ctx->current_cert));
if (!subject)
{
msg (D_TLS_ERRORS, "VERIFY ERROR: depth=%d, could not extract X509 subject string from certificate", ctx->error_depth);
@@ -3356,11 +3519,11 @@
/* preserve raw username before string_mod remapping, for plugins */
ALLOC_ARRAY_CLEAR_GC (raw_username, char, USER_PASS_LEN, &gc);
strcpy (raw_username, up->username);
- string_mod (raw_username, CC_PRINT, CC_CRLF, '_');
+ string_mod (raw_username, CC_PRINT|CC_MSB, CC_CRLF, '_');
/* enforce character class restrictions in username/password */
string_mod_sslname (up->username, COMMON_NAME_CHAR_CLASS, session->opt->ssl_flags);
- string_mod (up->password, CC_PRINT, CC_CRLF, '_');
+ string_mod (up->password, CC_PRINT|CC_MSB, CC_CRLF, '_');
/* call plugin(s) and/or script */
#ifdef MANAGEMENT_DEF_AUTH
Index: ssl.h
===
--- ssl.h (.../tags/openvpn-2.1_rc19) (revision 4645)
+++ ssl.h (.../trunk/openvpn-2.1_rc19) (revision 4645)
@@ -284,8 +284,8 @@
#define TLS_CN_LEN 64
/* Legal characters in an X509 or common name */
-#define X509_NAME_CHAR_CLASS (CC_ALNUM|CC_UNDERBAR|CC_DASH|CC_DOT|CC_AT|CC_COLON|CC_SLASH|CC_EQUAL)
-#define COMMON_NAME_CHAR_CLASS (CC_ALNUM|CC_UNDERBAR|CC_DASH|CC_DOT|CC_AT|CC_SLASH)
+#define X509_NAME_CHAR_CLASS (CC_ALNUM|CC_UNDERBAR|CC_DASH|CC_DOT|CC_AT|CC_COLON|CC_SLASH|CC_EQUAL|CC_MSB)
+#define COMMON_NAME_CHAR_CLASS (CC_ALNUM|CC_UNDERBAR|CC_DASH|CC_DOT|CC_AT|CC_SLASH|CC_MSB)
/* Maximum length of OCC options string passed as part of auth handshake */
#define TLS_OPTIONS_LEN 512
Index: buffer.c
===
--- buffer.c (.../tags/openvpn-2.1_rc19) (revision 4645)
+++ buffer.c (.../trunk/openvpn-2.1_rc19) (revision 4645)
@@ -692,7 +692,8 @@
if ((flags & CC_NULL) && c == '\0')
return true;
-
+ if ((flags & CC_MSB) && (c & 0x80))
+ return true;
if ((flags & CC_ALNUM) && isalnum (c))
return true;
if ((flags & CC_ALPHA) && isalpha (c))
Index: buffer.h
===
--- buffer.h (.../tags/openvpn-2.1_rc19) (revision 4645)
+++ buffer.h (.../trunk/openvpn-2.1_rc19) (revision 4645)
@@ -684,9 +684,10 @@
#define CC_REVERSE_QUOTE (1<<23)
#define CC_AT (1<<24)
#define CC_EQUAL (1<<25)
+#define CC_MSB (1<<26)
/* macro classes */
-#define CC_NAME (CC_ALNUM|CC_UNDERBAR)
+#define CC_NAME (CC_ALNUM|CC_UNDERBAR|CC_MSB)
#define CC_CRLF (CC_CR|CC_NEWLINE)
bool char_class (const unsigned char c, const unsigned int flags);
Re: [Openvpn-devel] Character classes in the tls-verify script
On 2009.10.24 at 13:39:56 -0600, James Yonan wrote: > Victor Wagner wrote: > > I've found out that string_mod family of function do very bad job > > with certificates with cyrillic characters in the subject. > > > > As of OpenVPN 2.1_rc19 class CC_PRINT is determined by function > > isprint from ctype.h, which does wrong job if there was no setlocale > > call (and there is no setlocale call in the OpenVPN). > > > > Can you submit a patch (as an email attachment) with this fix? > > My only concern would be if there are ways an attacker could use chars > that are >= 128 to attack a shell or server-side auth script. > > I think it would be better to have this turned off by default, but have > an option to enable it, like the no-name-remapping option in 2.1. If this option wouldn't conflict with script-security 3 system (as "no-name-remapping" does, it would be nice. Tomorrow I'd cut this patch out of my patch to openvpn 2.1rc19 It would require some time, because I now use OpenVPN with following addititonal functionality: 1. Support for non-HMAC packet authentication algorithm (requires OpenSSL 1.0, where support for non-HMAC MAC algorithms appeared) 2. Support for loading private keys from crypto hardware module via OpenSSL engine API, not PKCS11 API, using other engine than set by engine configuration parameter. 3. Export of certificate extension subjectAltName to scripts. 4. Support for CC_MSB character class.
[Openvpn-devel] Character classes in the tls-verify script
I've found out that string_mod family of function do very bad job with certificates with cyrillic characters in the subject. As of OpenVPN 2.1_rc19 class CC_PRINT is determined by function isprint from ctype.h, which does wrong job if there was no setlocale call (and there is no setlocale call in the OpenVPN). Moreover, all printable data except ones produced by X509_NAME_oneline function is produced by ASN1_STRING_to_UTF8 functions and no one guaranties that current locale of openvpn process has UTF-8 codeset. I've fixed this problem by defining new character class CC_MSB, which all bytes from UTF-8 multibyte sequence belong to, allow this character class everywhere where CC_PRINT is allowed and include it into macro definition of X509_NAME_CHAR_CLASS and COMMON_NAME_CHAR_CLASS I think that it is enough for security purposes, because no shell would ever treat unicode codepoints above 128 as word or command separators. And it gives me valid utf-8 string in the script variables and logs. But may be there exist better solution.
Re: [Openvpn-devel] Unable to use -OFB or -CFB ciphers in OpenVPN
On 2009.06.01 at 07:45:13 -0500, dave wrote: > I would suspect that the exclusion is due to: > > A) in CFB/OFB/CNT, the encrypted stream is byte-bounded, as opposed to > block-bounded. There may be some assumptions in the code that assume > the cipher text is a multiple of block lengths. As such, it is... It is valid argument. Is there some quick way to find out suspicious places in the code? Some amount of false positives is Ok. > B) not thoroughly tested, and the choice was made to not release it > without such testing. As far as I can see, openvpn can be thoroughly tested in automated fashion. I have some test farm with half a hundred various OSes (Linux, Windows, Solaris, FreeBSD on several architectures), and planning to do some openvpn testing for this platform anyway. If people would suggest me which things to test, I'll try to implement it in the automated test environment. > I'm curious as to why you want this support specifically, since these > modes aren't really faster than CBC. Are you concerned about the > padding? I've stated it clearly. There is no CBC in the Russian National Standard for symmetric ciphers. CFB is standartized, CNT is standartized, CBC is not. So, if I want my VPNs to be considered secure by goverment certification authorites, I have to use CFB or CNT. > > -dave >
Re: [Openvpn-devel] Unable to use -OFB or -CFB ciphers in OpenVPN
On 2009.05.30 at 04:38:41 -0600, James Yonan wrote: > > The OFB and CFB cipher modes in OpenVPN have not been well-tested and > should be considered experimental at this point. > They are not compiled by default mostly to prevent someone from > accidentally using them. Okay, you see there is some demand for this cipher. Can anybody explain why such strange design decision is taken. As far as I know cryptography theory, there is absolutely no reason to prefer CBC to CFB or CNT.
Re: [Openvpn-devel] Unable to use -OFB or -CFB ciphers in OpenVPN
On 2009.05.27 at 23:17:39 -0700, Frank Yellin wrote: >[Just to you, not the list.] >I figured that someone had to have noticed this problem before. But >when I googled "OpenVPN BF-OFB" or "OpenVPN BF-CFB", I couldn't find >anything. Of course you haven't find anything about Blowfish cipher. If you ask about GOST 28147-89, you might be more lucky. Really, mentioned GOST (Russian State Standard) doesn't specify CBC mode at all. It specifies CNT (gammirovanie) and CFB (gammirovanie s obrantoy sv'az'u). RFC 4357 does add CBC mode for GOST, but RFC is just "request for comments", and if I want to deploy OpenVPN in some Russian goverment organization, they would ask for national standard ciphers, not for RFC compliant. So, gost-cbc wasn't added to OpenSSL 1.0 while CFB (named gost89) and gost-cnt were. So, when adding GOST support into OpenVPN (really, that means support for GOST ciphers and TLS ciphersuides, if underlying OpenSSL supports them) I have to use CFB. >This bug is particularly strange because just before the bug, there is >code that's supposed to deal with -CFB and -OFB mode. But then it >doesn't do anything. It almost feels like this code was never tested. It seems so. We haven't yet investigated all problems we encountered with openvpn + gost CFB. Some of our problems was rather related with oldish TUN driver for Solaris (which are hopefully solved). And we have a lot of other OpenSSL-based applications besides OpenVPN to test. >I didn't have any trouble with my brief tests using BF-CFB over UDP, I'll note it. May be we should add this cipher into our test suite to isolate CFB-related problem from problems with dynamically loadable engines (GOST is implemented as engine) and problems with non-HMAC macs (which required a lot more patching than CFB, because at the time OpenVPN was designed, OpenSSL has no support form non-hmac MACs) >once I deleted the offending line. But I wasn't trying anything >difficult. Mainly just making sure the connection was there and that >it didn't die. We typically do following: 1. Start the connection 2. Download some file from peer via HTTP (using wget) 3. Download another, bigger file, to be sure that key renegotiation occur.
Re: [Openvpn-devel] Unable to use -OFB or -CFB ciphers in OpenVPN
On 2009.05.27 at 10:48:30 -0700, Frank Yellin wrote: >I posted the following onto the OpenVPN forum, but it was suggested >that I would be better off mailing directly to this list. >= >I seem to have found a bug in 2.1_rc16 that is also apparent in earlier >versions. Although OpenVPN claims to support -CFB and -OFB cipher >modes, using them seems to cause OpenVPN to crash consistently. > >For example, when I run the simple TLS example on the 2.1 documentation >page, it works fine. But if I add "--cipher bf-cfb" to both the client >and server command lines, one or the other will crash. The error >message is always "Assertion failed at crypto.c:162". The crasher is >always the first one to try and send an encrypted message. I've reported this problem more than a year ago, but nothing changed. I really don't understand why openvpn prefers CBC modes. There is nothing wrong with CFB and OFB neither from securith nor from performance point of view. But it is not only problem with non-CBC ciphers. If you try to use preshared keys, you'll find out that they are explicitely disabled unless --test-crypto option is given, even if your compile with -DALLOW_NON_CBC_CIPHERS. Also, I've encountered some problems with UDP transport and stream ciphers which I haven't find time to debug yet.
Re: [Openvpn-devel] Solaris questions
On 2009.04.26 at 18:39:46 +0400, Victor Wagner wrote: > Of course. See attached patch (configure.patch). Unfortunately, I've send untested patch. I've checked configure invocation, but was too haste to check whether produced Makefile would work. Now there is tested patch. Only thing is that to do make install without root rights (which is common thing when building package and installing into temporary directory) you need /usr/ucb/install from SUNscpu package. Either included install-sh or GNU install from sunfreeware fails for unability to chown files. With this patch I've been able to build package for Solaris 8,9,10 both i386 and sparc. And all Sparc packages and 10/intel contain both 64-bit and 32-bit drivers. I do not attach packaging Makefile yet, becouse it depends on my solaris packaging scripts, which are not published anywhere. Index: tuntap/configure.in diff -ru tuntap.orig/configure.in tuntap/configure.in --- tuntap.orig/configure.in 2007-06-24 19:00:44.0 +0400 +++ tuntap/configure.in 2009-04-26 19:18:18.0 +0400 @@ -24,14 +24,22 @@ AC_PROG_CC AC_PROG_INSTALL +AC_ARG_ENABLE([64bit], + [ --disable-64bit disable build of 64-bit driver], +[use_64bit="$enableval"],[use_64bit=yes]) + +if test "$use_64bit" = "yes" +then AC_CHECK_PROG(ISAINFO, isainfo, yes, no, /usr/bin) -if test "$ISAINFO" = "yes" ; +else +ISAINFO=no +fi +if test "$ISAINFO" = "yes" -a "$use_64bit" = "yes"; then KARCH=`/usr/bin/isainfo -k` else -KARCH='i386' +KARCH=`uname -p` fi - case $KARCH in 'sparc' | 'i386') M64_OPT="" @@ -50,7 +58,7 @@ TUN_VER="$REL `date '+%m/%d/%Y'`"; export TUN_VER AC_ARG_ENABLE(debug, - --enable-debugEnable debuging, +[ --enable-debug Enable debuging], AC_DEFINE(TUN_DEBUG, 1) ) Index: tuntap/Makefile.in diff -ru tuntap.orig/Makefile.in tuntap/Makefile.in --- tuntap.orig/Makefile.in 2006-04-28 19:38:13.0 +0400 +++ tuntap/Makefile.in 2009-04-26 19:53:35.0 +0400 @@ -50,15 +50,18 @@ $(CC) $(CFLAGS) -c tun.c -o tap.o -DTUNTAP_TAP install: modules - $(INSTALL) -m 644 -o root -g root if_tun.h /usr/include/net - $(INSTALL) -m 644 -o root -g root tun $(DRV_DIR) - $(INSTALL) -m 644 -o root -g root tap $(DRV_DIR) - $(INSTALL) -m 644 -o root -g root tun.conf $(DRV_CONF_DIR) - $(INSTALL) -m 644 -o root -g root tap.conf $(DRV_CONF_DIR) - -$(REM_DRV) tun >/dev/null 2>&1 - -$(REM_DRV) tap >/dev/null 2>&1 - $(ADD_DRV) tun - $(ADD_DRV) tap + [ -n "$(DESTDIR)" ] && $(INSTALL) -d -m 0755 -o root -g bin $(DESTDIR)/usr/include/net + [ -n "$(DESTDIR)" ] && $(INSTALL) -d -m 0755 -o root -g sys $(DESTDIR)$(DRV_DIR) + $(INSTALL) -m 644 -o root -g root if_tun.h $(DESTDIR)/usr/include/net + $(INSTALL) -m 644 -o root -g root tun $(DESTDIR)$(DRV_DIR) + $(INSTALL) -m 644 -o root -g root tap $(DESTDIR)$(DRV_DIR) + $(INSTALL) -m 644 -o root -g root tun.conf $(DESTDIR)$(DRV_CONF_DIR) + $(INSTALL) -m 644 -o root -g root tap.conf $(DESTDIR)$(DRV_CONF_DIR) + + -[ -z "$(DESTDIR)" ]&& $(REM_DRV) tun >/dev/null 2>&1 + -[ -z "$(DESTDIR)" ]&& $(REM_DRV) tap >/dev/null 2>&1 + -[ -z "$(DESTDIR)" ]&& $(ADD_DRV) tun + -[ -z "$(DESTDIR)" ]&& $(ADD_DRV) tap clean: rm -f tun tap *.o *~
Re: [Openvpn-devel] Solaris questions
On 2009.04.25 at 16:31:14 +0900, Kazuyoshi Aizawa wrote: > Hi Victor, > > Could you please post the script once you have built drivers for your package? > So that I can update my script as well. > I've wanted to make script to be capable to build drivers on various > platforms. But I don't have enough systems which can use for test. > So if you would share your information, it would be appreciated. Of course. See attached patch (configure.patch). _This patch does following changes:_ 1. If isainfo not found, use uname -p to determine architecture instead of just fall back to i386. I assume that uname is always here on any Unix system. 2. Add --disable-64bit argument. If it is not given, everything work as before. If it is given, search for isainfo is disabled, and uname -p is used to determine architecture (and it always give 32-bit architecture). 3. Support for DESTDIR variable is added to make install. If this variable is given in the make command line (i.e.) make install DESTDIR=`pwd`/pkg-tmp files would be installed into $DESTDIR/usr/kernel instead of /usr/kernel and no add_drv/rem_drv would be run. It is helpful when building a package to be installed on different machines, but not one which is used for building. _Things this patch doesn't do:_ It would be nice to check whether ld used is GNU ld or SUN ld, and use correct ld options in each case (-m64 for GNU ld, and -64 for SUN ld). But I always use SUN ld, so I didn't give this change a high priority It would be nice to check whether our cc is GCC or Sun Studio and use correct options for each compiler. But I don't have Sun Studio installed on any of my machines. _Applying patch:_ chdir to directory of driver sources and run patch -p1 < (whereever you've put attached configure.patch) Using a patch program from SUNWcsu package (/usr/bin/patch) is OK (although it choke on plain diff -u output.) _BTW:_ Why do you distribute modified tun.c file instead of patch? Using patch has following advantages: 1. If some changes was done in upstream, which do not touch patched functionality, patch produced with diff -u or diff -c probably would still apply and do the right thing 2. If there are incompatible changes in upstream, patch most likely would break and user would clearly see that something goes wrong. 3. Your modified tun.c for openvpn-2.1rc15 is 4452 lines, and unified diff between it and original one is 214 lines. I'm attaching this patch too (solaris.tap.patch). It should be applied with patch -p0 If you are interested, I would send my packaging makefiles which produce solaris package for your driver, which can be installed on both 32 and 64-bit machines. But somewhat later, because I've not finished them yet. Sincerely yours, Victor Index: tuntap/Makefile.in diff -ru tuntap/Makefile.in tuntap.patched/Makefile.in --- tuntap/Makefile.in Пт апр. 28 19:38:13 2006 +++ tuntap.patched/Makefile.in Вс апр. 26 18:10:18 2009 @@ -50,15 +50,16 @@ $(CC) $(CFLAGS) -c tun.c -o tap.o -DTUNTAP_TAP install: modules - $(INSTALL) -m 644 -o root -g root if_tun.h /usr/include/net - $(INSTALL) -m 644 -o root -g root tun $(DRV_DIR) - $(INSTALL) -m 644 -o root -g root tap $(DRV_DIR) - $(INSTALL) -m 644 -o root -g root tun.conf $(DRV_CONF_DIR) - $(INSTALL) -m 644 -o root -g root tap.conf $(DRV_CONF_DIR) - -$(REM_DRV) tun >/dev/null 2>&1 - -$(REM_DRV) tap >/dev/null 2>&1 - $(ADD_DRV) tun - $(ADD_DRV) tap + $(INSTALL) -m 644 -o root -g root if_tun.h $(DESTDIR)/usr/include/net + $(INSTALL) -m 644 -o root -g root tun $(DESTDIR)$(DRV_DIR) + $(INSTALL) -m 644 -o root -g root tap $(DESTDIR)$(DRV_DIR) + $(INSTALL) -m 644 -o root -g root tun.conf $(DESTDIR)$(DRV_CONF_DIR) + $(INSTALL) -m 644 -o root -g root tap.conf $(DESTDIR)$(DRV_CONF_DIR) + -[ -n "$(DESTDIR)" ]&& $(REM_DRV) tun >/dev/null 2>&1 + -[ -n "$(DESTDIR)" ]&& $(REM_DRV) tap >/dev/null 2>&1 + -[ -n "$(DESTDIR)" ]&& $(ADD_DRV) tun + -[ -n "$(DESTDIR)" ]&& $(ADD_DRV) tap +endif clean: rm -f tun tap *.o *~ Index: tuntap/configure.in diff -ru tuntap/configure.in tuntap.patched/configure.in --- tuntap/configure.in Вс июня 24 19:00:44 2007 +++ tuntap.patched/configure.in Вс апр. 26 18:15:54 2009 @@ -24,14 +24,22 @@ AC_PROG_CC AC_PROG_INSTALL +AC_ARG_ENABLE([64bit], + [ --disable-64bit disable build of 64-bit driver], +[use_64bit="$enableval"],[use_64bit=yes]) + +if test "$use_64bit" = "yes" +then AC_CHECK_PROG(ISAINFO, isainfo, yes, no, /usr/bin) -if test "$ISAINFO" = "yes" ; +else +ISAINFO=no +fi +if test "$ISAINFO" = "yes" -a "$use_64bit" = "yes"; then KARCH=`/usr/bin/isainfo -k` else -KARCH='i386' +KARCH=`uname -p` fi - case $KARCH in 'sparc' | 'i386') M64_OPT="" @@ -50,7 +58,7 @@ TUN_VER="$REL `date '+%m/%d/%Y'`"; export TUN_VER AC_ARG_ENABLE(debug, - --enable-debugEnable debuging, +[ --enable-debug Enable debuging], AC_DEFINE(TUN_DEBUG, 1) ) Index
Re: [Openvpn-devel] Solaris questions
On 2009.04.24 at 07:47:54 -0700, Jonathan Petersson wrote: > Hi Victor, > > I haven't tried this myself and this guide is mainly for OpenSolaris, but: > http://blogs.reucon.com/srt/2008/12/17/installing_openvpn_on_opensolaris_2008_11.html There is nothing particulary interesting here, except than linker switches for GNU ld (and I use Solaris LD anyway) > The issue you're seeing with the driver can be remediated by using this patch: > http://www.whiteboard.ne.jp/~admin2/tuntap/ I know of this updated driver. Unfortunately I haven't figured out way how to build 32-bit version of this driver on 64-bit machine. (I almost forgot autoconf language and would have to dig into docs for few hours to remember enough of it to add something like --disable-64bit). And my task is to build a package which can be installed on any machine. So, I have to build both versions of driver on systems which support 64 bit.
[Openvpn-devel] Solaris questions
Hi, all I've tried to build Solaris OpenVPN packages for various versions of solaris and encountered some problems, probably related more with TUN driver, than with openvpn itself I'm using openvpn 2.1rc15 and tun driver 1.1 as recommended on openvpn.net site. 1. Openvpn is unable to close tun interface, if daemon is not running with root priveleges. with increased debug level it reports "not owner". 2. I was unable to run two openvpn daemons at once. First one starts, and second is unable to open another tun interface. These problems was experienced on Solaris 10 intel both with 32-bit and 64-bit (amd64) kernel, and Solaris 10 sparc, 64-bit kernel. Is this known issue and is there any workarounds/patches
[Openvpn-devel] Using OpenVPN with non-default cryptoalgorithms
I'm trying to use OpenVPN with GOST cryptoalgorithms, which are now
available in the OpenSSL 0.9.9 (development version).
I've found some things which looks strange to me, and want to know
why some design decisions are made :
1. CBC mode. Why CBC mode is so prefered over CFB or OFB?
GOST 28147 doesn't define CBC mode at all, although CBC mode for GOST is
defined in RFC 4357, it is considered "substandard" and current
ccgost engine in OpenSSL doesn't implement it. I've always thought
that CBC is least secure mode of cipher. But openvpn require rebuild
with special define to use non-CBC ciphers. And error message
mistakenly tells that CFB ciphers would be supported only in TLS
mode, while they do work in shared-secret mode.
2. Assertion that EVP_CipherFinal would return buffer with size equal to
cipher's iv length.
Such assertion is found in file crypto.c line 168. (both 2.0.9 and
2.1_rc4 versions)
But it is not always true. For CFB cipher with blocksize of 1
EVP_CipherFinal would always return 0 bytes.
3. --dh argument is required in TLS server mode. It is really needed
only if ciphersuites with ephemeral DH key exchange are enabled.
But there are lot of other ciphersuites which do not require DH
parameters at all (or require some other parameters such as EECDH
ciphersuites).
Can somebody enlighten me - why these decisions were made?
Regards, Victor Wagner.
