axtls-general Mailing List for axTLS Embedded SSL (Page 3)
Brought to you by:
cameronrich
You can subscribe to this list here.
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2011 |
Jan
(13) |
Feb
(1) |
Mar
|
Apr
(3) |
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2012 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(1) |
May
(4) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
(4) |
Jul
(4) |
Aug
(2) |
Sep
(3) |
Oct
(1) |
Nov
(4) |
Dec
(1) |
2015 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
(2) |
Aug
(8) |
Sep
|
Oct
|
Nov
|
Dec
(3) |
2017 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(2) |
Aug
(1) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
|
2019 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Chris G. <ch...@se...> - 2014-06-17 23:02:50
|
Hi, I have been using axTLS for a few years on an embedded client (powerpc-linux, typically 32mb RAM) and until recently it has met my needs, but I've run into an interoperability problem. Recently a customer complained that when they disable "insecure renegotiation" but enable "secure renegotiation" on their Microsoft Threat Management Gateway server, my company's client devices are unable to connect. The server admins are claiming the reason for this is axTLS does not support RFC5746 <http://tools.ietf.org/html/rfc5746>. The symptom is that the server closes the connection immediately after client hello. I have found that axTLS does not add the renegotiation_info extension or null cipher suite "TLS_EMPTY_RENEGOTIATION_INFO_SCSV" described in section 3 of RFC5746 <http://tools.ietf.org/html/rfc5746#section-3>. Per my reading of that RFC the server may immediately drop the connection if these are not present, and I think that is what is happening. I suppose I may be the only one to ever run across this. For comparison, recent OpenSSL uses TLS_EMPTY_RENEGOTIATION_INFO_SCSV when forced to use TLS 1.1 and in TLS 1.2 mode it uses the renegotiation_info extension. What do you think would be the best way to correct this? -- Chris Ghormley / Set-Point Control |
From: David S. <sh...@al...> - 2014-02-17 16:39:50
|
Hello, I've made a git-svn mirror of the sourceforge svn repo and pushed it to GitHub here <https://github.com/dsheets/axtls>. Then, when playing with axssl, I wanted the openssl s_client command flag -ign_eof to put axssl at the end of a pipeline and still print the socket buffer. In the process of doing that, I found a pair of small bugs in axssl s_client and s_server's ssl_writes use in which it would write null-terminated strings when the input was not null-terminated. These bugs (as well as null byte reception bugs and the implementation of the -ign_eof flag) have been addressed in my axssl branch at <https://github.com/dsheets/axtls/tree/axssl>. Thanks for all your work on axTLS! I'm writing some OCaml bindings so I'm interested in improving all the OpenSSL compatibility interfaces. I'd love to have someone review my patches. :-) Best regards, David Sheets |
From: Medina <joa...@gm...> - 2013-02-25 19:01:26
|
Hi Guys!! I´m planning to use axTLS in an embedded system and found out about this vulnerability. Is this fix already addressed to someone? Thanks, João Carlos |
From: Cameron R. <cam...@gm...> - 2012-05-25 23:17:15
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> </head> <body bgcolor="#ffffff" text="#000000"> Hi everybody,<br> <br> There's a new version of axTLS v1.4.6 that fixes the following issues:<br> <h4><u>SSL Library</u></h4> <ul> <li> Fixed issue where the stdint typedefs were not imported by default (stdint.h had to be included explicity) (thanks Anthony G. Basile)</li> <li> Fixed RNG initialization issue where client library was performed incorrectly (thanks Gilles Boccon~-Gibod). </li> </ul> <br> <h4><u>axhttpd</u></h4> <ul> <li> Now compiles properly under TCP/IP v6.</li> </ul> Cheers,<br> <br> Cam<br> </body> </html> |
From: Cameron R. <cam...@gm...> - 2012-05-25 11:17:35
|
Hi Arunkumar, axTLS is guaranteed to be thread safe if multiple SSL contexts are used. However parallel calls to ssl_read() and ssl_write() were never considered as the buffers they use are the same to save memory. So locking is the next step, and I've never really had the need for this, as axTLS was never designed for high performance I/O. I think this might be non-trivial to do as the code changes could be quite invasive. I have the same problem with non-blocking ssl_read/ssl_write calls - axTLS can be made to be almost non-blocking but in some cases it will. High performance has been sacrificed for code/memory size. But feel free to write a patch and I'll see what I can do. Cheers, Cam Arunkumar Dhananjayn wrote: > Hi All, > > We are using axTLS in our embedded project and need to perform > ssl_write() and ssl_read() from different threads. But Valgrind tool > reported a race condition on the ssl->flag and ssl->bm_data fields. On > further investigation it looks like, the code was not written to support > performing read and write operations simultaneously. > > Can anyone confirm this? How much of a priority is this to other developers? > > We are planning to perform crude locking so that only read of write > happens at a time, although I think it should be possible to do it > without a lock if the fields used for write and read operations are > separated. Is anyone interested in the changes? > > thanks, > arun > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > axtls-general mailing list > axt...@li... > https://lists.sourceforge.net/lists/listinfo/axtls-general > > |
From: Arunkumar D. <dar...@cl...> - 2012-05-23 10:57:28
|
Hi All, We are using axTLS in our embedded project and need to perform ssl_write() and ssl_read() from different threads. But Valgrind tool reported a race condition on the ssl->flag and ssl->bm_data fields. On further investigation it looks like, the code was not written to support performing read and write operations simultaneously. Can anyone confirm this? How much of a priority is this to other developers? We are planning to perform crude locking so that only read of write happens at a time, although I think it should be possible to do it without a lock if the fields used for write and read operations are separated. Is anyone interested in the changes? thanks, arun |
From: Arunkumar D. <dar...@cl...> - 2012-05-22 12:02:57
|
Hi All, I am trying to use axTLS in an embedded system which we regularly run in a simulated mode on Linux and check for any issues using Valgrind. After adding axTLS, we noticed Valgrind complaining about conditional jump depending on unitialized value. I traced the issue to the get_random() function, which uses the inbuilt algorithm. This seems to be copying utmost ENTROPY_POOL_SIZE random data to the requested buffer and uses the remaining uninitialized values in the RC4_crypt() function. I really want to prevent this Valgrind message, so that we have a clean output. I am just wondering if the axTLS code really needs to be fixed to avoid using the uninitialized data in the input buffer as a source of entropy. Is it really a secure practice? I just initialized the remaining of the buffer with 0s before calling the RC4_crypt() function. Will this still ensure good randomness? thanks, arun |
From: Anthony G. B. <ba...@op...> - 2012-04-07 02:19:32
|
Hi all Just thought I'd say hi to the list and mention that I'm maintaining axTLS for gentoo. I originally introduced it for curl, but I'm sure people will find other (ab)uses for it. -- Anthony G. Basile, Ph. D. Chair of Information Technology D'Youville College Buffalo, NY 14201 (716) 829-8197 |
From: Shiro K. <sh...@la...> - 2012-01-22 14:11:25
|
Hi there, I'm new to axTLS, and trying to see if I can bundle it to my software---it is much smaller than several other open-source TLS implementations. I have a question regarding the error message generated by ssltest. * Platform: Linux (Ubuntu 10.04LTS, x86_64) * Configuration: The .config file attached. * Building: After building by 'make' at the toplevel, I cd'ed to ssl/test and ran 'make ssltesting' to create ssltest (because I was curious.) * Symptom: When I ran ssltest under _stage, the test passes, but I see a couple of messages during certificate tests: Error: Invalid X509 ASN.1 file (Unsupported digest) They are generated in the call: ssl_obj_load(ssl_ctx, SSL_OBJ_X509_CACERT, "../ssl/test/ca-bundle.crt", NULL) And specifically, the certificate #133 and #137 in ca-bundle.crt are causing these messages. My question is if this is a known issue and I can ignore them, or it indicates my build is somewhat broken. Regards, |
From: Gerald S. <gs...@st...> - 2011-04-11 15:47:15
|
Cam, I received word back from our developers and they have the timer set at 300 sec as shown below. But we are not seeing any timeout on browser. How do we get this to timeout? I have tried leaving the web page open for several days, rebooting the device that contains the web server, switching the device that contains the web server to another one, continually updating the web page from the browser for over 5 minutes, and it never times out/logs me out. x x [*] Static Build x x x x (80) HTTP port x x x x (443) HTTPS port x x x x (5) SSL session cache size x x x x (/) Web root location x x x x (300) Timeout x x x x CGI ---> x x x x [ ] Enable Directory Listing x x x x [*] Enable authorization x x x x [ ] Enable IPv6 x x x x [ ] Enable different user x x x x [ ] Verbose Mode x x x x [ ] Run as a daemon Is there something I am missing or not understanding? Thanks, Gerald From: Cameron Rich [mailto:cam...@gm...] Sent: Friday, April 08, 2011 5:44 PM To: Gerald Smith Cc: axt...@li... Subject: Re: Questions on axTLS version 1.2.9 There is one and it's set to 5 minutes by default. However it sits on the other side of a blocking select() statement. So the timeout relies on regular http traffic to force the socket to be closed. This is obviously not 100% desirable, but the web server takes 0% CPU when idle which is great for embedded devices. The other option is to regularly drop out of the select() and make the check but at the cost of CPU cycles. So it was a conscious decision but perhaps one that should be reviewed at some stage now that embedded devices these days are becoming so much more powerful. Cam Gerald Smith wrote: Mr. Rich, We are using this web server but have noticed that there does not seem to be an inactivity timer to log the user out after so much time without any activity. Is there an inactivity timer that we are not aware of? If not, are there plans to support one on a future release? Thanks, Gerald |
From: Daniel S. <da...@ha...> - 2011-01-26 07:45:35
|
On Wed, 26 Jan 2011, Cameron Rich wrote: > I'll be making a new version in the next few days, but for now it's a > subversion update. Awesome, thanks! I'll certainly make sure to check it out as soon as I can. -- / daniel.haxx.se |
From: Daniel S. <da...@ha...> - 2011-01-19 22:33:16
|
On Wed, 19 Jan 2011, Hu, Eric wrote: > Because things are working for us, I may not have time to look at this for a > while, but I like what I hear from your description. Perhaps one of the > libcurl folks can run some quick tests with your new code. Dan Stenberg is > subscribed here, but in case he's busy, I'll post to the libcurl mailing > list too. I just built and installed axTLS svnversion 198. Using this (and everything else unchanged), I'm sorry to say that curl can't do anything over SSL anymore... None of its own tests and not with the command line I've tried before: $ curl -k -v https://sourceforge.net/ -L -- / daniel.haxx.se |
From: Hu, E. <EHu@DIRECTV.com> - 2011-01-19 18:26:17
|
Hi Cam, > I've checked a version of axTLS that should keep you and the libcurl > guys reasonably happy. > My specific application was actually okay with axTLS switching the socket over to blocking under the hood. In one place, we were using axTLS 1.1.5, which didn't have this yet, but once that got switched to 1.2.7 (and subsequently 1.3.1), things worked for us. > I've removed the code that converts the socket into blocked mode. So > almost non-blocked but I believe it should be close enough for your > requirements. Let me know what you think. > Because things are working for us, I may not have time to look at this for a while, but I like what I hear from your description. Perhaps one of the libcurl folks can run some quick tests with your new code. Dan Stenberg is subscribed here, but in case he's busy, I'll post to the libcurl mailing list too. Thanks, Eric |
From: Daniel S. <da...@ha...> - 2011-01-14 09:31:51
|
On Fri, 14 Jan 2011, Cameron Rich wrote: > An axTLS application should only have a limited number of clients attached > at any one time (typically one). The intention is that axTLS is on very > small devices with limited I/O. The question of blocking or not isn't so much about how many clients or connections you use, I see it more as about being forced to do all connections in separate threads or not. In a design where the SSL is done purely blocking, chances are that it won't be good enough for particular applications so they instead are forced to use threads or multiple processes to achieve the responsiveness they require. More threads are more resource intense and in fact, which I always tend to stress, are much harder to debug - especially on embedded systems where the set of debug tools tend to be more limited - than single threaded designs. Not to mention the case that Eric brings here: a small device that wants to use libcurl's multi interface to do non-blocking operations, possibly doing more than one transfer in parallel... > axTLS is simply not designed for big servers - it was never the primary > goal. If axTLS is ever used for major server work (which I would actually > find amusing), then I might pursue it further - but it would probably > involve a fork. I doubt Eric talks about "big servers" use, and I know I certainly am not. But I suspect that the "small device" you're talking about is much smaller than the "small device" that I think about. Two competitors to axTLS that I'm aware of that also focus pretty much on embedded/small systems are yaSSL and PolarSSL. AFAIK, both of them do non- blocking operations. -- / daniel.haxx.se |
From: Daniel S. <da...@ha...> - 2011-01-12 22:06:21
|
Hi friends, We recently got libcurl (http://curl.haxx.se/libcurl/) the ability to build and run with axTLS doing the TLS layer and we've really enjoyed the recent improvements done to axTLS. Very good work! There are still a few problems and after discussions on the libcurl mailing list I'd like to highlight the biggest problem I have right now (using the SVN revision 193 which is the latest right now): I still can't connect to public sites using my Debian Linux default ca cert bundle (/etc/ssl/certs/). I have changed CONFIG_X509_MAX_CA_CERTS to 200. I tried HTTPS with these sites: sourceforge.net paypal.com www.skandiabanken.se www.google.com sites.google.com www.target.com www.hotmail.com www.yahoo.com. They all work fine if I just disable certificate verification. My test script: #!/bin/sh for i in sourceforge.net paypal.com www.skandiabanken.se www.google.com \ sites.google.com www.target.com www.hotmail.com www.yahoo.com ; do cmd="./src/curl https://$i -k -s -o /dev/null" echo $cmd eval $cmd echo $? done ... it's easy to change to use the system curl or to not use -k etc. -- / daniel.haxx.se |
From: Cameron R. <cam...@gm...> - 2011-01-11 09:59:38
|
A new release with the following changes: * Certificate bundles which contain "invalid" certificates (i.e. invalid digests types etc) are ignored rather than cause failure. * HTTPv1.0 packets close a connection upon completion. I've also done some minor clean-up with scan-build. Cheers, Cam |
From: Cameron R. <cam...@gm...> - 2011-01-02 23:03:18
|
Version 1.2.9 had a couple of Valgrind issues (read/writes out of bounds). So these have been fixed and I've released a new version accordingly. Cheers, Cam |
From: Cameron R. <cam...@gm...> - 2011-01-02 10:12:14
|
Latest changes described here: http://axtls.sourceforge.net/README/index.html. Cheers, Cam |
From: Daniel S. <da...@ha...> - 2010-12-27 12:40:52
|
Hi! It's nice to see another release of axTLS. Thanks! A few problems we (in the curl project) still notice: - it still can't read the ca cert bundle used in stock Debian (/etc/ssl/certs/ca-certificates.crt) - it still pollutes the name space by #defining malloc, calloc and realloc in the public header (we have to #undef them manually). - there are some possible flaws identified with scan-build, see the attachment for an analyze run I just did on a SVN checkout (rev 180) - valgrind also whines on some things, but I don't quite understand them so until I've analyzed them further I'll treat them as false positives -- / daniel.haxx.se |