From INVALID.NOREPLY at gnu.org Sat Jan 3 23:49:37 2015 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Sat, 03 Jan 2015 22:49:37 +0000 Subject: [gnutls-devel] [sr #108712] mutiple DTLS records in one UDP packet not handled correctly In-Reply-To: <20141230-141206.sv97952.32759@savannah.gnu.org> References: <20141230-141206.sv97952.32759@savannah.gnu.org> Message-ID: <20150104-004937.sv707.51400@savannah.gnu.org> Follow-up Comment #1, sr #108712 (project gnutls): Hi, From what I understand from your description gnutls has read 251 bytes out of a 16732 UDP packet and returns GNUTLS_E_AGAIN. That seems to be the expected behavior. It doesn't call recv() multiple times to avoid blocks, and expects you to restore the handshake function if you know there are more data in the socket buffers (e.g., using select in standard socket functions). In your case as I understand you do the buffering so you should be able to know whether there are pending data or not. Is there something I am missing? _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Sun Jan 4 16:58:22 2015 From: INVALID.NOREPLY at gnu.org (Andreas Schultz) Date: Sun, 04 Jan 2015 15:58:22 +0000 Subject: [gnutls-devel] [sr #108712] mutiple DTLS records in one UDP packet not handled correctly In-Reply-To: <20150104-004937.sv707.51400@savannah.gnu.org> References: <20141230-141206.sv97952.32759@savannah.gnu.org> <20150104-004937.sv707.51400@savannah.gnu.org> Message-ID: <20150104-155822.sv97952.13244@savannah.gnu.org> Follow-up Comment #2, sr #108712 (project gnutls): > From what I understand from your description gnutls has read 251 bytes out of a 16732 UDP packet No, gnutls told the pull function that the supplied buffer is 16732 bytes long, the pull function reads a UDP packet of 251 bytes and copies those 251 bytes into the supplied buffer. The 251 byte UDP packet does contain a total of three (3) DTLS records. The first record is 158 bytes long and does contain the last fragment of the server certificate, the second record contains a certificate request and the third record is the server hello done. gnutls now processes only the first record, ignores the two others and return GNUTLS_E_AGAIN. There is no data in the socket buffer left at this point, all of it was passed to gnutls and is no in gnutls internal buffers. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Sun Jan 4 18:06:03 2015 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Sun, 04 Jan 2015 17:06:03 +0000 Subject: [gnutls-devel] [sr #108712] mutiple DTLS records in one UDP packet not handled correctly In-Reply-To: <20150104-155822.sv97952.13244@savannah.gnu.org> References: <20141230-141206.sv97952.32759@savannah.gnu.org> <20150104-004937.sv707.51400@savannah.gnu.org> <20150104-155822.sv97952.13244@savannah.gnu.org> Message-ID: <20150104-190603.sv707.11438@savannah.gnu.org> Follow-up Comment #3, sr #108712 (project gnutls): I'm unable to reproduce. Are you testing with the latest release? If yes, could you modify the attached program to make it reproduce the issue? It uses the libutils from the tests/ directory in gnutls. You can compile it as: gcc mini-dtls-srecord.c -lgnutls .libs/libutils.a (file #32757) _______________________________________________________ Additional Item Attachment: File name: mini-dtls-srecord.c Size:7 KB _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From ametzler at bebt.de Sun Jan 4 18:20:05 2015 From: ametzler at bebt.de (Andreas Metzler) Date: Sun, 4 Jan 2015 18:20:05 +0100 Subject: [gnutls-devel] gnutls-cli-dbg SMTP STARTTLS support broken, sends ehlo too early Message-ID: <20150104172005.GB1256@downhill.g.la> Hello, gnutls-cli-dbg --app-proto=smtp does not work since it immediately sends the EHLO before waiting for the server's 220 message. (And it does not wait for 250 later on.) Attached patch (against GIT master) seems to work for me. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -------------- next part -------------- A non-text attachment was scrubbed... Name: smtp_starttls_syncronisation_error.diff Type: text/x-diff Size: 648 bytes Desc: not available URL: From nmav at gnutls.org Sun Jan 4 20:37:47 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 04 Jan 2015 20:37:47 +0100 Subject: [gnutls-devel] gnutls-cli-dbg SMTP STARTTLS support broken, sends ehlo too early In-Reply-To: <20150104172005.GB1256@downhill.g.la> References: <20150104172005.GB1256@downhill.g.la> Message-ID: <1420400267.5377.0.camel@gnutls.org> On Sun, 2015-01-04 at 18:20 +0100, Andreas Metzler wrote: > Hello, > > gnutls-cli-dbg --app-proto=smtp does not work since it immediately > sends the EHLO before waiting for the server's 220 message. (And it > does not wait for 250 later on.) Attached patch (against GIT master) > seems to work for me. Applied, thank you. From INVALID.NOREPLY at gnu.org Mon Jan 5 12:11:02 2015 From: INVALID.NOREPLY at gnu.org (Andreas Schultz) Date: Mon, 05 Jan 2015 11:11:02 +0000 Subject: [gnutls-devel] [sr #108712] mutiple DTLS records in one UDP packet not handled correctly In-Reply-To: <20150104-190603.sv707.11438@savannah.gnu.org> References: <20141230-141206.sv97952.32759@savannah.gnu.org> <20150104-004937.sv707.51400@savannah.gnu.org> <20150104-155822.sv97952.13244@savannah.gnu.org> <20150104-190603.sv707.11438@savannah.gnu.org> Message-ID: <20150105-111101.sv97952.70815@savannah.gnu.org> Follow-up Comment #4, sr #108712 (project gnutls): Got a working demo and it doesn't even the non-blocking socket. However, when looking more closely at the socket code, I found another potential problem. DTLS UDP sockets use writev to push out all parts for the handshake flight. writev will combine all iovec's into one single UDP datagram when the path MTU permits it. This defeats the purpose of gnutls_dtls_set_mtu. Should I open a new ticket for this? (file #32761) _______________________________________________________ Additional Item Attachment: File name: mini-dtls-srecord.c Size:8 KB _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Mon Jan 5 13:07:43 2015 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Mon, 05 Jan 2015 12:07:43 +0000 Subject: [gnutls-devel] [sr #108712] mutiple DTLS records in one UDP packet not handled correctly In-Reply-To: <20150105-111101.sv97952.70815@savannah.gnu.org> References: <20141230-141206.sv97952.32759@savannah.gnu.org> <20150104-004937.sv707.51400@savannah.gnu.org> <20150104-155822.sv97952.13244@savannah.gnu.org> <20150104-190603.sv707.11438@savannah.gnu.org> <20150105-111101.sv97952.70815@savannah.gnu.org> Message-ID: <20150105-140743.sv707.55412@savannah.gnu.org> Follow-up Comment #5, sr #108712 (project gnutls): Yes, would be nice. If you have a reproducer please attach it as well. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Mon Jan 5 15:31:24 2015 From: INVALID.NOREPLY at gnu.org (Andreas Schultz) Date: Mon, 05 Jan 2015 14:31:24 +0000 Subject: [gnutls-devel] [sr #108715] DTLS send does not respect MTU Message-ID: <20150105-143123.sv97952.70115@savannah.gnu.org> URL: Summary: DTLS send does not respect MTU Project: GnuTLS Submitted by: roadrunnr Submitted on: Mon 05 Jan 2015 02:31:23 PM GMT Category: None Priority: 5 - Normal Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: None _______________________________________________________ Details: The DTLS send function does not respect the MTU set via gnutls_dtls_set_mtu. DTLS does fragment the record, but it passes all fragments on to writev, which will slap them all together into one datagram, ignoring the explicitly set MTU. Test case for reproduction attached. _______________________________________________________ File Attachments: ------------------------------------------------------- Date: Mon 05 Jan 2015 02:31:23 PM GMT Name: mini-dtls-mtu.c Size: 8kB By: roadrunnr _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Mon Jan 5 16:34:00 2015 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Mon, 05 Jan 2015 15:34:00 +0000 Subject: [gnutls-devel] [sr #108715] DTLS send does not respect MTU In-Reply-To: <20150105-143123.sv97952.70115@savannah.gnu.org> References: <20150105-143123.sv97952.70115@savannah.gnu.org> Message-ID: <20150105-173400.sv707.70920@savannah.gnu.org> Follow-up Comment #1, sr #108715 (project gnutls): Thank you. I've committed a fix at: https://gitorious.org/gnutls/gnutls/commit/43082a67c7514d65301d157fb567a133138a85ab _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Mon Jan 5 16:34:52 2015 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Mon, 05 Jan 2015 15:34:52 +0000 Subject: [gnutls-devel] [sr #108712] mutiple DTLS records in one UDP packet not handled correctly In-Reply-To: <20150105-140743.sv707.55412@savannah.gnu.org> References: <20141230-141206.sv97952.32759@savannah.gnu.org> <20150104-004937.sv707.51400@savannah.gnu.org> <20150104-155822.sv97952.13244@savannah.gnu.org> <20150104-190603.sv707.11438@savannah.gnu.org> <20150105-111101.sv97952.70815@savannah.gnu.org> <20150105-140743.sv707.55412@savannah.gnu.org> Message-ID: <20150105-173452.sv707.3525@savannah.gnu.org> Update of sr #108712 (project gnutls): Status: None => Invalid Open/Closed: Open => Closed _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Mon Jan 5 16:43:17 2015 From: INVALID.NOREPLY at gnu.org (Andreas Schultz) Date: Mon, 05 Jan 2015 15:43:17 +0000 Subject: [gnutls-devel] [sr #108712] mutiple DTLS records in one UDP packet not handled correctly In-Reply-To: <20150105-173452.sv707.3525@savannah.gnu.org> References: <20141230-141206.sv97952.32759@savannah.gnu.org> <20150104-004937.sv707.51400@savannah.gnu.org> <20150104-155822.sv97952.13244@savannah.gnu.org> <20150104-190603.sv707.11438@savannah.gnu.org> <20150105-111101.sv97952.70815@savannah.gnu.org> <20150105-140743.sv707.55412@savannah.gnu.org> <20150105-173452.sv707.3525@savannah.gnu.org> Message-ID: <20150105-154317.sv97952.92188@savannah.gnu.org> Follow-up Comment #6, sr #108712 (project gnutls): Why is this "invalid" ???? Could you point out what in the test case is incorrect usage, please? _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Mon Jan 5 16:52:49 2015 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Mon, 05 Jan 2015 15:52:49 +0000 Subject: [gnutls-devel] [sr #108712] mutiple DTLS records in one UDP packet not handled correctly In-Reply-To: <20150105-154317.sv97952.92188@savannah.gnu.org> References: <20141230-141206.sv97952.32759@savannah.gnu.org> <20150104-004937.sv707.51400@savannah.gnu.org> <20150104-155822.sv97952.13244@savannah.gnu.org> <20150104-190603.sv707.11438@savannah.gnu.org> <20150105-111101.sv97952.70815@savannah.gnu.org> <20150105-140743.sv707.55412@savannah.gnu.org> <20150105-173452.sv707.3525@savannah.gnu.org> <20150105-154317.sv97952.92188@savannah.gnu.org> Message-ID: <20150105-175249.sv707.14029@savannah.gnu.org> Follow-up Comment #7, sr #108712 (project gnutls): I thought you mentioned that you couldn't reproduce it in comment #4. Feel free to re-open it if I misunderstood. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Mon Jan 5 16:53:53 2015 From: INVALID.NOREPLY at gnu.org (Andreas Schultz) Date: Mon, 05 Jan 2015 15:53:53 +0000 Subject: [gnutls-devel] [sr #108715] DTLS send does not respect MTU In-Reply-To: <20150105-173400.sv707.70920@savannah.gnu.org> References: <20150105-143123.sv97952.70115@savannah.gnu.org> <20150105-173400.sv707.70920@savannah.gnu.org> Message-ID: <20150105-155353.sv97952.32631@savannah.gnu.org> Follow-up Comment #2, sr #108715 (project gnutls): mhh, yeah that fixes this specific MTU problem. Maybe it should be documented that the GNUTLS DTLS network layer does not implemented any of the SHOULD's from RFC 6347 section 4.1.1.1. (https://tools.ietf.org/html/rfc6347#section-4.1.1.1) _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Mon Jan 5 16:59:59 2015 From: INVALID.NOREPLY at gnu.org (Andreas Schultz) Date: Mon, 05 Jan 2015 15:59:59 +0000 Subject: [gnutls-devel] [sr #108712] mutiple DTLS records in one UDP packet not handled correctly In-Reply-To: <20150105-175249.sv707.14029@savannah.gnu.org> References: <20141230-141206.sv97952.32759@savannah.gnu.org> <20150104-004937.sv707.51400@savannah.gnu.org> <20150104-155822.sv97952.13244@savannah.gnu.org> <20150104-190603.sv707.11438@savannah.gnu.org> <20150105-111101.sv97952.70815@savannah.gnu.org> <20150105-140743.sv707.55412@savannah.gnu.org> <20150105-173452.sv707.3525@savannah.gnu.org> <20150105-154317.sv97952.92188@savannah.gnu.org> <20150105-175249.sv707.14029@savannah.gnu.org> Message-ID: <20150105-155959.sv97952.79861@savannah.gnu.org> Follow-up Comment #8, sr #108712 (project gnutls): Bad wording on my side. I was able to reproduce it. Test case to reproduce is in file #32761 Seems I'm not allowed to change the status of the bug (or I'm unable to find out how). _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Mon Jan 5 17:10:42 2015 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Mon, 05 Jan 2015 16:10:42 +0000 Subject: [gnutls-devel] [sr #108715] DTLS send does not respect MTU In-Reply-To: <20150105-155353.sv97952.32631@savannah.gnu.org> References: <20150105-143123.sv97952.70115@savannah.gnu.org> <20150105-173400.sv707.70920@savannah.gnu.org> <20150105-155353.sv97952.32631@savannah.gnu.org> Message-ID: <20150105-181042.sv707.14040@savannah.gnu.org> Follow-up Comment #3, sr #108715 (project gnutls): Could you be more specific? What is missing? _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Mon Jan 5 17:11:11 2015 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Mon, 05 Jan 2015 16:11:11 +0000 Subject: [gnutls-devel] [sr #108712] mutiple DTLS records in one UDP packet not handled correctly In-Reply-To: <20150105-155959.sv97952.79861@savannah.gnu.org> References: <20141230-141206.sv97952.32759@savannah.gnu.org> <20150104-004937.sv707.51400@savannah.gnu.org> <20150104-155822.sv97952.13244@savannah.gnu.org> <20150104-190603.sv707.11438@savannah.gnu.org> <20150105-111101.sv97952.70815@savannah.gnu.org> <20150105-140743.sv707.55412@savannah.gnu.org> <20150105-173452.sv707.3525@savannah.gnu.org> <20150105-154317.sv97952.92188@savannah.gnu.org> <20150105-175249.sv707.14029@savannah.gnu.org> <20150105-155959.sv97952.79861@savannah.gnu.org> Message-ID: <20150105-181111.sv707.44822@savannah.gnu.org> Update of sr #108712 (project gnutls): Status: Invalid => In Progress Open/Closed: Closed => Open _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Mon Jan 5 17:51:19 2015 From: INVALID.NOREPLY at gnu.org (Andreas Schultz) Date: Mon, 05 Jan 2015 16:51:19 +0000 Subject: [gnutls-devel] [sr #108715] DTLS send does not respect MTU In-Reply-To: <20150105-181042.sv707.14040@savannah.gnu.org> References: <20150105-143123.sv97952.70115@savannah.gnu.org> <20150105-173400.sv707.70920@savannah.gnu.org> <20150105-155353.sv97952.32631@savannah.gnu.org> <20150105-181042.sv707.14040@savannah.gnu.org> Message-ID: <20150105-165119.sv97952.90435@savannah.gnu.org> Follow-up Comment #4, sr #108715 (project gnutls): ok, after reading the RFC again, if have to admit that "any" was way to strong. Most things are there and it just difficult from the documentation to understand what exactly the application has to implement and what is present in the library. The examples are also that helpful, as they don't adjust the MTU in the case or errors. So here is what I found surprising: >From RFC6347, Section 4.1.1.1: > If there is a transport protocol indication (either via ICMP or via a > refusal to send the datagram as in Section 14 of [DCCP]), then the > DTLS record layer MUST inform the upper layer protocol of the error. That works only partially. The second part: > or via a refusal to send the datagram does work, the push function would return the error and all is well. However with datagram sockets, sending an over sized datagram does not always result in an immediate EMSGSIZE error (at least under linux). At least under Linux, the EMSGSIZE is only returned if the datagram size exceeds the CACHED Path MTU. The Path MTU is initially assumed to be the same as the interface MTU (mostly 1500). So GNUTLS will not report the proper error in the following scenario: * initial state: unknown peer, PMTU assumed to be YY * during handshake a datagram with YY bytes (minus header overhead) is sent, the writev call will not return an error * a ICMP Packet Too Big (max size XX bytes) is send from a router in the path and the packet is lost This ICMP error is not read nor handled in the DTLS layer. The only indication the caller gets is after the transmission timer expires and GNUTLS tries to send the packet again. > discovery. In order to allow connections under these circumstances, > DTLS implementations SHOULD follow the following rules: > > - If the DTLS record layer informs the DTLS handshake layer that a > message is too big, it SHOULD immediately attempt to fragment it, > using any existing information about the PMTU. I might be wrong, but as far as I can see, there is no code that queries the underlying OS for the MTU (getsockopt IP_MTU under Linux) in case of a EMSGSIZE, nor does there seem to be any code to adjust the MTU. All of this is left to the application to handle. > - If repeated retransmissions do not result in a response, and the > PMTU is unknown, subsequent retransmissions SHOULD back off to a > smaller record size, fragmenting the handshake message as > appropriate. This standard does not specify an exact number of > retransmits to attempt before backing off, but 2-3 seems > appropriate. It is arguable if this should be part of the library or not. None of the above is an error, it just is a bit surprising. The manual does mention it briefly in chapter 6.5.2: > The ?correct? maximum transfer unit can be obtained through a path MTU discovery mechanism [RFC4821]. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Mon Jan 5 19:20:01 2015 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Mon, 05 Jan 2015 18:20:01 +0000 Subject: [gnutls-devel] [sr #108712] mutiple DTLS records in one UDP packet not handled correctly In-Reply-To: <20150105-181111.sv707.44822@savannah.gnu.org> References: <20141230-141206.sv97952.32759@savannah.gnu.org> <20150104-004937.sv707.51400@savannah.gnu.org> <20150104-155822.sv97952.13244@savannah.gnu.org> <20150104-190603.sv707.11438@savannah.gnu.org> <20150105-111101.sv97952.70815@savannah.gnu.org> <20150105-140743.sv707.55412@savannah.gnu.org> <20150105-173452.sv707.3525@savannah.gnu.org> <20150105-154317.sv97952.92188@savannah.gnu.org> <20150105-175249.sv707.14029@savannah.gnu.org> <20150105-155959.sv97952.79861@savannah.gnu.org> <20150105-181111.sv707.44822@savannah.gnu.org> Message-ID: <20150105-202000.sv707.20228@savannah.gnu.org> Follow-up Comment #9, sr #108712 (project gnutls): Interesting case. Here you are artificially setting the client's MTU to 400 bytes, and the server's to 1500. The certificate is 558 so the client cannot receive it with the size of its buffers. In a real world case (when ICMP packets are allowed) the server should have received GNUTLS_E_LARGE_PACKET and should have adjusted its view of MTU size. Is there some particular merit in addressing that? I mean are there real scenarios where this case could occur? _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Mon Jan 5 19:33:24 2015 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Mon, 05 Jan 2015 18:33:24 +0000 Subject: [gnutls-devel] [sr #108715] DTLS send does not respect MTU In-Reply-To: <20150105-165119.sv97952.90435@savannah.gnu.org> References: <20150105-143123.sv97952.70115@savannah.gnu.org> <20150105-173400.sv707.70920@savannah.gnu.org> <20150105-155353.sv97952.32631@savannah.gnu.org> <20150105-181042.sv707.14040@savannah.gnu.org> <20150105-165119.sv97952.90435@savannah.gnu.org> Message-ID: <20150105-203324.sv707.92071@savannah.gnu.org> Follow-up Comment #5, sr #108715 (project gnutls): >> If there is a transport protocol indication (either via ICMP or via a >> refusal to send the datagram as in Section 14 of [DCCP]), then the >> DTLS record layer MUST inform the upper layer protocol of the error. >That works only partially. The second part: >> or via a refusal to send the datagram >does work, the push function would return the error and all is well. >However with datagram sockets, sending an over sized datagram does not always result in an immediate EMSGSIZE error (at least under linux). Correct. We rely on the OS for that. > This ICMP error is not read nor handled in the DTLS layer. The only indication the caller gets is after the transmission timer expires and GNUTLS tries to send the packet again. Indeed. I don't think we can do better than that though. Not with the standard sockets API at least. I'm open to suggestions on that. > I might be wrong, but as far as I can see, there is no code that queries the underlying OS for the MTU (getsockopt IP_MTU under Linux) in case of a EMSGSIZE, nor does there seem to be any code to adjust the MTU. All of this is left to the application to handle. You are correct. There is no generic or cross-platform API to handle that so the application is responsible to discover and set the MTU. Not sure how better we can do on that. >> - If repeated retransmissions do not result in a response, and the >> PMTU is unknown, subsequent retransmissions SHOULD back off to a >> smaller record size, fragmenting the handshake message as >> appropriate. This standard does not specify an exact number of >> retransmits to attempt before backing off, but 2-3 seems >> appropriate. > It is arguable if this should be part of the library or not. I would really have liked to include MTU handling as part of the library. However, it is very tricky to handle in all cases. There are real world scenarios where EMSGSIZE is never returned, from the OS because ICMP packets are blocked from the firewall. That, and the fact that MTU handling is restricted to handshake only, were the main reason it was not part of the library. Having said that, I think it would be a nice idea to add a flag in gnutls_init() which makes MTU adjustment transparent, for the handshake at least. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Tue Jan 6 11:18:05 2015 From: INVALID.NOREPLY at gnu.org (Andreas Schultz) Date: Tue, 06 Jan 2015 10:18:05 +0000 Subject: [gnutls-devel] [sr #108712] mutiple DTLS records in one UDP packet not handled correctly In-Reply-To: <20150105-202000.sv707.20228@savannah.gnu.org> References: <20141230-141206.sv97952.32759@savannah.gnu.org> <20150104-004937.sv707.51400@savannah.gnu.org> <20150104-155822.sv97952.13244@savannah.gnu.org> <20150104-190603.sv707.11438@savannah.gnu.org> <20150105-111101.sv97952.70815@savannah.gnu.org> <20150105-140743.sv707.55412@savannah.gnu.org> <20150105-173452.sv707.3525@savannah.gnu.org> <20150105-154317.sv97952.92188@savannah.gnu.org> <20150105-175249.sv707.14029@savannah.gnu.org> <20150105-155959.sv97952.79861@savannah.gnu.org> <20150105-181111.sv707.44822@savannah.gnu.org> <20150105-202000.sv707.20228@savannah.gnu.org> Message-ID: <20150106-101804.sv97952.74908@savannah.gnu.org> Follow-up Comment #10, sr #108712 (project gnutls): > Interesting case. Here you are artificially setting the client's MTU to 400 bytes, and the server's to 1500. The certificate is 558 so the client cannot receive it with the size of its buffers. In a real world case (when ICMP packets are allowed) the server should have received GNUTLS_E_LARGE_PACKET and should have adjusted its view of MTU size. Correction, I set the servers MTU to 400, the client's is left at 1500. Artificial lowering the permitted MTU below the Path MTU is IMO a valid use case and I have seen at least on real world server insisting on such a low MTU (Cisco Virtual Wireless Controller) > Is there some particular merit in addressing that? I mean are there real scenarios where this case could occur? Well, this sample is contrive to simulate a specific scenario that would not occur with GNUTLS alone. What the test does is to generate a payload that the client sees as one big datagram containing multiple fragmented DTLS records. GNUTLS does not generate this kind of datagram, but they are valid and OpenSSL does generate them. So for the test to be reproducible without involving OpenSSL I had to come up with some contrived code. Particularity, running DTLS over a streaming socket that does not preserve the packet boundaries of sending side (this simulates the "big datagram containing multiple DTLS records") and setting a low sender side MTU to get the fragmentation. So, to answer your question, yes there are real world scenarios where this case will occur. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Tue Jan 6 21:34:05 2015 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Tue, 06 Jan 2015 20:34:05 +0000 Subject: [gnutls-devel] [sr #108712] mutiple DTLS records in one UDP packet not handled correctly In-Reply-To: <20150106-101804.sv97952.74908@savannah.gnu.org> References: <20141230-141206.sv97952.32759@savannah.gnu.org> <20150104-004937.sv707.51400@savannah.gnu.org> <20150104-155822.sv97952.13244@savannah.gnu.org> <20150104-190603.sv707.11438@savannah.gnu.org> <20150105-111101.sv97952.70815@savannah.gnu.org> <20150105-140743.sv707.55412@savannah.gnu.org> <20150105-173452.sv707.3525@savannah.gnu.org> <20150105-154317.sv97952.92188@savannah.gnu.org> <20150105-175249.sv707.14029@savannah.gnu.org> <20150105-155959.sv97952.79861@savannah.gnu.org> <20150105-181111.sv707.44822@savannah.gnu.org> <20150105-202000.sv707.20228@savannah.gnu.org> <20150106-101804.sv97952.74908@savannah.gnu.org> Message-ID: <20150106-223405.sv707.42433@savannah.gnu.org> Follow-up Comment #11, sr #108712 (project gnutls): I believe the issue is due to your reproducer. In select() you use the wrong parameters and that's why it blocks there. I fixed that in: https://gitorious.org/gnutls/gnutls/commit/066db0b051a048e005f7bb344621b5ea931aeea3 https://gitorious.org/gnutls/gnutls/source/HEAD:tests/mini-dtls-record-asym.c and it seems to work. There is no issue handling these packets, whether combined in a single record or not. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Wed Jan 7 18:00:24 2015 From: INVALID.NOREPLY at gnu.org (Andreas Schultz) Date: Wed, 07 Jan 2015 17:00:24 +0000 Subject: [gnutls-devel] [sr #108712] mutiple DTLS records in one UDP packet not handled correctly In-Reply-To: <20150106-223405.sv707.42433@savannah.gnu.org> References: <20141230-141206.sv97952.32759@savannah.gnu.org> <20150104-004937.sv707.51400@savannah.gnu.org> <20150104-155822.sv97952.13244@savannah.gnu.org> <20150104-190603.sv707.11438@savannah.gnu.org> <20150105-111101.sv97952.70815@savannah.gnu.org> <20150105-140743.sv707.55412@savannah.gnu.org> <20150105-173452.sv707.3525@savannah.gnu.org> <20150105-154317.sv97952.92188@savannah.gnu.org> <20150105-175249.sv707.14029@savannah.gnu.org> <20150105-155959.sv97952.79861@savannah.gnu.org> <20150105-181111.sv707.44822@savannah.gnu.org> <20150105-202000.sv707.20228@savannah.gnu.org> <20150106-101804.sv97952.74908@savannah.gnu.org> <20150106-223405.sv707.42433@savannah.gnu.org> Message-ID: <20150107-170023.sv97952.92689@savannah.gnu.org> Follow-up Comment #12, sr #108712 (project gnutls): > I believe the issue is due to your reproducer. In select() you use the wrong parameters and that's why it blocks there. Yes, the select is wrong, but the problem is still there with the fixed select, only the DTLS re-transmission hides it. I attach a new version of mini-dtls-record-asym.c. This version makes sure the select times out before the DTLS re-transmission kicks in. (file #32782) _______________________________________________________ Additional Item Attachment: File name: mini-dtls-record-asym.c Size:8 KB _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Thu Jan 8 09:42:18 2015 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Thu, 08 Jan 2015 08:42:18 +0000 Subject: [gnutls-devel] [sr #108712] mutiple DTLS records in one UDP packet not handled correctly In-Reply-To: <20150107-170023.sv97952.92689@savannah.gnu.org> References: <20141230-141206.sv97952.32759@savannah.gnu.org> <20150104-004937.sv707.51400@savannah.gnu.org> <20150104-155822.sv97952.13244@savannah.gnu.org> <20150104-190603.sv707.11438@savannah.gnu.org> <20150105-111101.sv97952.70815@savannah.gnu.org> <20150105-140743.sv707.55412@savannah.gnu.org> <20150105-173452.sv707.3525@savannah.gnu.org> <20150105-154317.sv97952.92188@savannah.gnu.org> <20150105-175249.sv707.14029@savannah.gnu.org> <20150105-155959.sv97952.79861@savannah.gnu.org> <20150105-181111.sv707.44822@savannah.gnu.org> <20150105-202000.sv707.20228@savannah.gnu.org> <20150106-101804.sv97952.74908@savannah.gnu.org> <20150106-223405.sv707.42433@savannah.gnu.org> <20150107-170023.sv97952.92689@savannah.gnu.org> Message-ID: <20150108-104218.sv707.87574@savannah.gnu.org> Follow-up Comment #13, sr #108712 (project gnutls): Thanks for the update. I've committed a fix. https://gitorious.org/gnutls/gnutls/commit/bb616582ea8cce9880067a292f7fc031b19d315f _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From rick at vanrein.org Fri Jan 9 19:24:40 2015 From: rick at vanrein.org (Rick van Rein) Date: Fri, 9 Jan 2015 19:24:40 +0100 Subject: [gnutls-devel] cert-type check ignores retrieve_function2 Message-ID: <740B0A45-5419-44FB-A79F-E32FADBB8568@vanrein.org> Hello, When setting up TLS with cert-type OpenPGP from a client, the server verifies if it supports the extension?s contents in _gnutls_session_cert_type_supported(). This function checks for cred->get_cert_callback but not cred->get_cert_callback2. As a result, servers setup for OpenPGP certificate credential callback with gnutls_certificate_set_retrieve_function2() are unable to use the OpenPGP certificate type. This was first noticed on GnuTLS 3.2.1 and has been verified to still apply to GnuTLS 3.2.21. The solution is to consider cred->get_cert_callback2 alongside cred->get_cert_callback in _gnutls_session_cert_type_supported(). A patch to do this has been appended; it has been confirmed to solve the problem. An ugly workaround is to register a callback (for recognition of the extension support) and a callback2 (to override the previous callback), as on https://github.com/vanrein/tlspool/commit/4938102d3d1b086491d147e6c8e4e2a02825fc12 The problem was tested to be circumvented with either this workaround or the patch below (or both). I hope this is helpful. Cheers, -Rick -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls-3.2.21-certtype-extension-retrieve-function2.patch Type: application/octet-stream Size: 711 bytes Desc: not available URL: From nmav at gnutls.org Sat Jan 10 12:16:42 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 10 Jan 2015 12:16:42 +0100 Subject: [gnutls-devel] cert-type check ignores retrieve_function2 In-Reply-To: <740B0A45-5419-44FB-A79F-E32FADBB8568@vanrein.org> References: <740B0A45-5419-44FB-A79F-E32FADBB8568@vanrein.org> Message-ID: <1420888602.4475.1.camel@gnutls.org> On Fri, 2015-01-09 at 19:24 +0100, Rick van Rein wrote: > Hello, > > When setting up TLS with cert-type OpenPGP from a client, the server verifies if it supports the extension?s contents in _gnutls_session_cert_type_supported(). This function checks for cred->get_cert_callback but not cred->get_cert_callback2. As a result, servers setup for OpenPGP certificate credential callback with gnutls_certificate_set_retrieve_function2() are unable to use the OpenPGP certificate type. > > This was first noticed on GnuTLS 3.2.1 and has been verified to still apply to GnuTLS 3.2.21. > > The solution is to consider cred->get_cert_callback2 alongside cred->get_cert_callback in _gnutls_session_cert_type_supported(). A patch to do this has been appended; it has been confirmed to solve the problem. Thanks. I've pushed the fix, as well as a test case to avoid that issue in the future. regards, Nikos From INVALID.NOREPLY at gnu.org Sun Jan 11 14:22:52 2015 From: INVALID.NOREPLY at gnu.org (Luke Dashjr) Date: Sun, 11 Jan 2015 13:22:52 +0000 Subject: [gnutls-devel] [sr #108724] Configure option to avoid building tools Message-ID: <20150111-132251.sv86557.94568@savannah.gnu.org> URL: Summary: Configure option to avoid building tools Project: GnuTLS Submitted by: lukedashjr Submitted on: Sun 11 Jan 2015 13:22:51 GMT Category: Included programs Priority: 5 - Normal Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: GNU/Linux _______________________________________________________ Details: I would like to build gnutls without the included tools. Can a --disable-tools configure option be added? I can provide a patch, if necessary. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Mon Jan 12 10:55:34 2015 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Mon, 12 Jan 2015 09:55:34 +0000 Subject: [gnutls-devel] [sr #108724] Configure option to avoid building tools In-Reply-To: <20150111-132251.sv86557.94568@savannah.gnu.org> References: <20150111-132251.sv86557.94568@savannah.gnu.org> Message-ID: <20150112-115534.sv707.73467@savannah.gnu.org> Follow-up Comment #1, sr #108724 (project gnutls): Feel free to provide a patch. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Mon Jan 12 10:55:44 2015 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Mon, 12 Jan 2015 09:55:44 +0000 Subject: [gnutls-devel] [sr #108715] DTLS send does not respect MTU In-Reply-To: <20150105-203324.sv707.92071@savannah.gnu.org> References: <20150105-143123.sv97952.70115@savannah.gnu.org> <20150105-173400.sv707.70920@savannah.gnu.org> <20150105-155353.sv97952.32631@savannah.gnu.org> <20150105-181042.sv707.14040@savannah.gnu.org> <20150105-165119.sv97952.90435@savannah.gnu.org> <20150105-203324.sv707.92071@savannah.gnu.org> Message-ID: <20150112-115544.sv707.83997@savannah.gnu.org> Update of sr #108715 (project gnutls): Status: None => Done Open/Closed: Open => Closed _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Mon Jan 12 10:55:52 2015 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Mon, 12 Jan 2015 09:55:52 +0000 Subject: [gnutls-devel] [sr #108712] mutiple DTLS records in one UDP packet not handled correctly In-Reply-To: <20150108-104218.sv707.87574@savannah.gnu.org> References: <20141230-141206.sv97952.32759@savannah.gnu.org> <20150104-004937.sv707.51400@savannah.gnu.org> <20150104-155822.sv97952.13244@savannah.gnu.org> <20150104-190603.sv707.11438@savannah.gnu.org> <20150105-111101.sv97952.70815@savannah.gnu.org> <20150105-140743.sv707.55412@savannah.gnu.org> <20150105-173452.sv707.3525@savannah.gnu.org> <20150105-154317.sv97952.92188@savannah.gnu.org> <20150105-175249.sv707.14029@savannah.gnu.org> <20150105-155959.sv97952.79861@savannah.gnu.org> <20150105-181111.sv707.44822@savannah.gnu.org> <20150105-202000.sv707.20228@savannah.gnu.org> <20150106-101804.sv97952.74908@savannah.gnu.org> <20150106-223405.sv707.42433@savannah.gnu.org> <20150107-170023.sv97952.92689@savannah.gnu.org> <20150108-104218.sv707.87574@savannah.gnu.org> Message-ID: <20150112-115552.sv707.54046@savannah.gnu.org> Update of sr #108712 (project gnutls): Status: In Progress => Done Open/Closed: Open => Closed _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Mon Jan 12 20:34:13 2015 From: INVALID.NOREPLY at gnu.org (anonymous) Date: Mon, 12 Jan 2015 19:34:13 +0000 Subject: [gnutls-devel] [sr #108724] Configure option to avoid building tools In-Reply-To: <20150112-115534.sv707.73467@savannah.gnu.org> References: <20150111-132251.sv86557.94568@savannah.gnu.org> <20150112-115534.sv707.73467@savannah.gnu.org> Message-ID: <20150112-193412.sv0.50196@savannah.gnu.org> Additional Item Attachment, sr #108724 (project gnutls): File name: 0001-Added-configure-option-disable-tools.patch Size:4 KB _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Mon Jan 12 20:34:59 2015 From: INVALID.NOREPLY at gnu.org (Luke Dashjr) Date: Mon, 12 Jan 2015 19:34:59 +0000 Subject: [gnutls-devel] [sr #108724] Configure option to avoid building tools In-Reply-To: <20150112-193412.sv0.50196@savannah.gnu.org> References: <20150111-132251.sv86557.94568@savannah.gnu.org> <20150112-115534.sv707.73467@savannah.gnu.org> <20150112-193412.sv0.50196@savannah.gnu.org> Message-ID: <20150112-193459.sv86557.80019@savannah.gnu.org> Follow-up Comment #2, sr #108724 (project gnutls): Attached patch. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Mon Jan 12 22:59:29 2015 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Mon, 12 Jan 2015 21:59:29 +0000 Subject: [gnutls-devel] [sr #108724] Configure option to avoid building tools In-Reply-To: <20150112-193459.sv86557.80019@savannah.gnu.org> References: <20150111-132251.sv86557.94568@savannah.gnu.org> <20150112-115534.sv707.73467@savannah.gnu.org> <20150112-193412.sv0.50196@savannah.gnu.org> <20150112-193459.sv86557.80019@savannah.gnu.org> Message-ID: <20150112-235929.sv707.1807@savannah.gnu.org> Follow-up Comment #3, sr #108724 (project gnutls): Thanks. As it is quite an extensive patch, would you like to send the DCO to the list, as in http://www.gnutls.org/devel.html _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Mon Jan 12 23:46:25 2015 From: INVALID.NOREPLY at gnu.org (Luke Dashjr) Date: Mon, 12 Jan 2015 22:46:25 +0000 Subject: [gnutls-devel] [sr #108724] Configure option to avoid building tools In-Reply-To: <20150112-235929.sv707.1807@savannah.gnu.org> References: <20150111-132251.sv86557.94568@savannah.gnu.org> <20150112-115534.sv707.73467@savannah.gnu.org> <20150112-193412.sv0.50196@savannah.gnu.org> <20150112-193459.sv86557.80019@savannah.gnu.org> <20150112-235929.sv707.1807@savannah.gnu.org> Message-ID: <20150112-224625.sv86557.51576@savannah.gnu.org> Follow-up Comment #4, sr #108724 (project gnutls): DCO? _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Mon Jan 12 23:58:31 2015 From: INVALID.NOREPLY at gnu.org (Luke Dashjr) Date: Mon, 12 Jan 2015 22:58:31 +0000 Subject: [gnutls-devel] [sr #108724] Configure option to avoid building tools In-Reply-To: <20150112-224625.sv86557.51576@savannah.gnu.org> References: <20150111-132251.sv86557.94568@savannah.gnu.org> <20150112-115534.sv707.73467@savannah.gnu.org> <20150112-193412.sv0.50196@savannah.gnu.org> <20150112-193459.sv86557.80019@savannah.gnu.org> <20150112-235929.sv707.1807@savannah.gnu.org> <20150112-224625.sv86557.51576@savannah.gnu.org> Message-ID: <20150112-225831.sv86557.11533@savannah.gnu.org> Follow-up Comment #5, sr #108724 (project gnutls): Figured it out; sent. P.S. I'd suggest disabling spamhaus.easydns.com on the mailing list server if possible, they are lately abusing their position to put political pressure against entire ISPs. : host mx.easymail.ca[205.210.42.59] said: 554 5.7.1 Service unavailable; Client host [192.3.11.21] blocked using spamhaus.easydns.com; http://www.spamhaus.org/sbl/query/SBL240293 (in reply to RCPT TO command) _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Tue Jan 13 00:29:02 2015 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Mon, 12 Jan 2015 23:29:02 +0000 Subject: [gnutls-devel] [sr #108724] Configure option to avoid building tools In-Reply-To: <20150112-225831.sv86557.11533@savannah.gnu.org> References: <20150111-132251.sv86557.94568@savannah.gnu.org> <20150112-115534.sv707.73467@savannah.gnu.org> <20150112-193412.sv0.50196@savannah.gnu.org> <20150112-193459.sv86557.80019@savannah.gnu.org> <20150112-235929.sv707.1807@savannah.gnu.org> <20150112-224625.sv86557.51576@savannah.gnu.org> <20150112-225831.sv86557.11533@savannah.gnu.org> Message-ID: <20150113-012902.sv707.57029@savannah.gnu.org> Follow-up Comment #6, sr #108724 (project gnutls): I have no control over it. Post it here, if it is better. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Tue Jan 13 00:40:13 2015 From: INVALID.NOREPLY at gnu.org (Luke Dashjr) Date: Mon, 12 Jan 2015 23:40:13 +0000 Subject: [gnutls-devel] [sr #108724] Configure option to avoid building tools In-Reply-To: <20150113-012902.sv707.57029@savannah.gnu.org> References: <20150111-132251.sv86557.94568@savannah.gnu.org> <20150112-115534.sv707.73467@savannah.gnu.org> <20150112-193412.sv0.50196@savannah.gnu.org> <20150112-193459.sv86557.80019@savannah.gnu.org> <20150112-235929.sv707.1807@savannah.gnu.org> <20150112-224625.sv86557.51576@savannah.gnu.org> <20150112-225831.sv86557.11533@savannah.gnu.org> <20150113-012902.sv707.57029@savannah.gnu.org> Message-ID: <20150112-234012.sv86557.420@savannah.gnu.org> Follow-up Comment #7, sr #108724 (project gnutls): Spamhaus is unfortunately popular, so I am setup to easily evade it - did it not get through to the list? _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Tue Jan 13 22:49:35 2015 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Tue, 13 Jan 2015 21:49:35 +0000 Subject: [gnutls-devel] [sr #108724] Configure option to avoid building tools In-Reply-To: <20150112-234012.sv86557.420@savannah.gnu.org> References: <20150111-132251.sv86557.94568@savannah.gnu.org> <20150112-115534.sv707.73467@savannah.gnu.org> <20150112-193412.sv0.50196@savannah.gnu.org> <20150112-193459.sv86557.80019@savannah.gnu.org> <20150112-235929.sv707.1807@savannah.gnu.org> <20150112-224625.sv86557.51576@savannah.gnu.org> <20150112-225831.sv86557.11533@savannah.gnu.org> <20150113-012902.sv707.57029@savannah.gnu.org> <20150112-234012.sv86557.420@savannah.gnu.org> Message-ID: <20150113-234935.sv707.17238@savannah.gnu.org> Follow-up Comment #8, sr #108724 (project gnutls): No, I don't see anything in my mailbox or the archive. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Tue Jan 13 22:58:37 2015 From: INVALID.NOREPLY at gnu.org (Luke Dashjr) Date: Tue, 13 Jan 2015 21:58:37 +0000 Subject: [gnutls-devel] [sr #108724] Configure option to avoid building tools In-Reply-To: <20150113-234935.sv707.17238@savannah.gnu.org> References: <20150111-132251.sv86557.94568@savannah.gnu.org> <20150112-115534.sv707.73467@savannah.gnu.org> <20150112-193412.sv0.50196@savannah.gnu.org> <20150112-193459.sv86557.80019@savannah.gnu.org> <20150112-235929.sv707.1807@savannah.gnu.org> <20150112-224625.sv86557.51576@savannah.gnu.org> <20150112-225831.sv86557.11533@savannah.gnu.org> <20150113-012902.sv707.57029@savannah.gnu.org> <20150112-234012.sv86557.420@savannah.gnu.org> <20150113-234935.sv707.17238@savannah.gnu.org> Message-ID: <20150113-215836.sv86557.88179@savannah.gnu.org> Follow-up Comment #9, sr #108724 (project gnutls): Developer's Certificate of Origin 1.1 By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From nmav at gnutls.org Wed Jan 14 22:45:53 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 14 Jan 2015 22:45:53 +0100 Subject: [gnutls-devel] GnuTLS & TCP Fast Open ? In-Reply-To: <1598765.iusEFRnxJh@debian> References: <1598765.iusEFRnxJh@debian> Message-ID: <1421271953.12547.1.camel@gnutls.org> On Wed, 2015-01-14 at 21:52 +0100, Tim R?hsen wrote: > Hi, > > does GnuTLS currently support TFO and if yes, how do I tell GnuTLS to use it ? > And if no, are there any known caveats, especially regarding SSL/TLS in > general ? I've never used TFO, but there shouldn't be any issues with it. Protocol-wise most probably you want to send the client hello in advance and that hardly carries sensitive data. Overall this doesn't affect the security of TLS, as its threat model includes an attacker observing and injecting packets. Implementation-wise there is no special API for that, but providing a push function which will use sendto() (*) on the first message, and send() otherwise could do the trick. Other than that, the changes in server side, and the socket calls are independent and don't affect the usage of the gnutls' api. If you do have some working code it would be nice if you send your changes, or some documentation on that, so we can document it. *. Providing that the API in http://lwn.net/Articles/508865/ is the final one regards, Nikos From INVALID.NOREPLY at gnu.org Wed Jan 14 23:01:09 2015 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Wed, 14 Jan 2015 22:01:09 +0000 Subject: [gnutls-devel] [sr #108724] Configure option to avoid building tools In-Reply-To: <20150113-215836.sv86557.88179@savannah.gnu.org> References: <20150111-132251.sv86557.94568@savannah.gnu.org> <20150112-115534.sv707.73467@savannah.gnu.org> <20150112-193412.sv0.50196@savannah.gnu.org> <20150112-193459.sv86557.80019@savannah.gnu.org> <20150112-235929.sv707.1807@savannah.gnu.org> <20150112-224625.sv86557.51576@savannah.gnu.org> <20150112-225831.sv86557.11533@savannah.gnu.org> <20150113-012902.sv707.57029@savannah.gnu.org> <20150112-234012.sv86557.420@savannah.gnu.org> <20150113-234935.sv707.17238@savannah.gnu.org> <20150113-215836.sv86557.88179@savannah.gnu.org> Message-ID: <20150115-000109.sv707.66091@savannah.gnu.org> Follow-up Comment #10, sr #108724 (project gnutls): I realized that there some conditional checks in the patch similar to: if test "$enable_tools$enable_doc" != "no" if test "$enable_tools$enable_doc" != "nono" I find these quite confusing. Please resubmit a patch with clear such as: if test "$enable_tools" != "no" && test "$enable_doc" != "no" A question on the patch, is why do you do: +if ENABLE_TOOLS +SUBDIRS += src +else +SUBDIRS += src/gl +endif Why is the src/gl compiled if no tools are there? Other than these the patch looks ok. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Thu Jan 15 01:35:00 2015 From: INVALID.NOREPLY at gnu.org (Luke Dashjr) Date: Thu, 15 Jan 2015 00:35:00 +0000 Subject: [gnutls-devel] [sr #108724] Configure option to avoid building tools In-Reply-To: <20150115-000109.sv707.66091@savannah.gnu.org> References: <20150111-132251.sv86557.94568@savannah.gnu.org> <20150112-115534.sv707.73467@savannah.gnu.org> <20150112-193412.sv0.50196@savannah.gnu.org> <20150112-193459.sv86557.80019@savannah.gnu.org> <20150112-235929.sv707.1807@savannah.gnu.org> <20150112-224625.sv86557.51576@savannah.gnu.org> <20150112-225831.sv86557.11533@savannah.gnu.org> <20150113-012902.sv707.57029@savannah.gnu.org> <20150112-234012.sv86557.420@savannah.gnu.org> <20150113-234935.sv707.17238@savannah.gnu.org> <20150113-215836.sv86557.88179@savannah.gnu.org> <20150115-000109.sv707.66091@savannah.gnu.org> Message-ID: <20150115-003459.sv86557.48724@savannah.gnu.org> Follow-up Comment #11, sr #108724 (project gnutls): Doc examples use src/gl (file #32826) _______________________________________________________ Additional Item Attachment: File name: 0001-Added-configure-option-disable-tools.patch Size:4 KB _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From tim.ruehsen at gmx.de Thu Jan 15 14:50:21 2015 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Thu, 15 Jan 2015 14:50:21 +0100 Subject: [gnutls-devel] OCSP for www.google.com Message-ID: <4350608.UCMoa1nDjP@blitz-lx> Hi, using gnutls-cli (3.3.11-1 from Debian Experimental) with --ocsp does not work for www.google.com. My question is, does gnutls and/or google fail ? From 'gnutls-cli --ocsp -V www.google.com' I see three certs returned: Processed 171 CA certificate(s). Resolving 'www.google.com'... Connecting to '173.194.113.179:443'... - Certificate type: X.509 - Got a certificate list of 3 certificates. - Certificate[0] info: ... Extensions: Authority Information Access (not critical): Access Method: 1.3.6.1.5.5.7.48.2 (id-ad-caIssuers) Access Location URI: http://pki.google.com/GIAG2.crt Access Method: 1.3.6.1.5.5.7.48.1 (id-ad-ocsp) Access Location URI: http://clients1.google.com/ocsp ... - Certificate[1] info: ... Extensions: Authority Information Access (not critical): Access Method: 1.3.6.1.5.5.7.48.1 (id-ad-ocsp) Access Location URI: http://g.symcd.com ... - Certificate[2] info: [does not matter] ... - Status: The certificate is trusted. Connecting to OCSP server: g.symcd.com... Resolving 'g.symcd.com'... Connecting to '23.37.43.27:80'... *** Got OCSP response with no data (ignoring) *** OCSP response ignored... From what I found on the internet, http://clients1.google.com/ocsp should be OCSP-requested, not http://g.symcd.com though Certificate[1] seems to be the issuer for Certificate[1]. Could you please have a look at it ? And/or give some advise what to do ? Thank you ! Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From nmav at gnutls.org Thu Jan 15 15:54:16 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 15 Jan 2015 15:54:16 +0100 Subject: [gnutls-devel] OCSP for www.google.com In-Reply-To: <4350608.UCMoa1nDjP@blitz-lx> References: <4350608.UCMoa1nDjP@blitz-lx> Message-ID: On Thu, Jan 15, 2015 at 2:50 PM, Tim Ruehsen wrote: > Hi, > using gnutls-cli (3.3.11-1 from Debian Experimental) with --ocsp does not work > for www.google.com. My question is, does gnutls and/or google fail ? It seems gnutls-cli (and ocsptool) fail early when they don't understand the first entry in the AIA extension. This patch on ocsptool fixes the issue: https://gitorious.org/gnutls/gnutls/commit/11eebe14b232ec198d1446a3720e6ed78d118c4b regards, Nikos From tim.ruehsen at gmx.de Thu Jan 15 16:18:50 2015 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Thu, 15 Jan 2015 16:18:50 +0100 Subject: [gnutls-devel] OCSP for www.google.com In-Reply-To: References: <4350608.UCMoa1nDjP@blitz-lx> Message-ID: <3047578.e0qapIJ357@blitz-lx> On Thursday 15 January 2015 15:54:16 Nikos Mavrogiannopoulos wrote: > On Thu, Jan 15, 2015 at 2:50 PM, Tim Ruehsen wrote: > > Hi, > > using gnutls-cli (3.3.11-1 from Debian Experimental) with --ocsp does not > > work for www.google.com. My question is, does gnutls and/or google fail ? > It seems gnutls-cli (and ocsptool) fail early when they don't > understand the first entry in the AIA extension. > > This patch on ocsptool fixes the issue: > https://gitorious.org/gnutls/gnutls/commit/11eebe14b232ec198d1446a3720e6ed78 > d118c4b Wow Nikos, that was fast ! Thank you. I'll try it out soon. Just a follow-up question regarding OCSP. Looking at http://security.stackexchange.com/questions/56239/secure-connection-failed-ocsp, there is a comment: "By the way, OCSP stapling can only staple info for one certificate. The browser will still have to contact your intermediate certificates' OCSP servers unless you've recently visited another website using the same ones. (There's an RFC for stapling multiple certs in progress.) ? Matt Nordhoff" To me, this sounds reasonable. Shouldn't the ocsptool loop over the complete cert list and check each cert ? What do you think ? Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From nmav at gnutls.org Thu Jan 15 16:53:22 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 15 Jan 2015 16:53:22 +0100 Subject: [gnutls-devel] OCSP for www.google.com In-Reply-To: <3047578.e0qapIJ357@blitz-lx> References: <4350608.UCMoa1nDjP@blitz-lx> <3047578.e0qapIJ357@blitz-lx> Message-ID: On Thu, Jan 15, 2015 at 4:18 PM, Tim Ruehsen wrote: > Wow Nikos, that was fast ! Thank you. > I'll try it out soon. > Just a follow-up question regarding OCSP. > Looking at http://security.stackexchange.com/questions/56239/secure-connection-failed-ocsp, there is a comment: > > "By the way, OCSP stapling can only staple info for one certificate. The > browser will still have to contact your intermediate certificates' OCSP > servers unless you've recently visited another website using the same ones. > (There's an RFC for stapling multiple certs in progress.) - Matt Nordhoff" > To me, this sounds reasonable. Shouldn't the ocsptool loop over the complete > cert list and check each cert ? What do you think ? Indeed, that would be the right thing to do. If there is a patch for that I'll apply it. For completeness there is also rfc6961, which allows for multiple OCSP staples to be included in the server's reply, but doesn't seem to be supported by anyone. I have an implementation in some branch of gnutls, but as I couldn't make interop check with anyone, it is left out. regards, Nikos From tim.ruehsen at gmx.de Thu Jan 15 17:16:33 2015 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Thu, 15 Jan 2015 17:16:33 +0100 Subject: [gnutls-devel] OCSP for www.google.com In-Reply-To: References: <4350608.UCMoa1nDjP@blitz-lx> <3047578.e0qapIJ357@blitz-lx> Message-ID: <4530590.9XomAdVBFJ@blitz-lx> On Thursday 15 January 2015 16:53:22 Nikos Mavrogiannopoulos wrote: > On Thu, Jan 15, 2015 at 4:18 PM, Tim Ruehsen wrote: > > Wow Nikos, that was fast ! Thank you. > > I'll try it out soon. I put the code into mget and works like a charm ! > > Just a follow-up question regarding OCSP. > > Looking at > > http://security.stackexchange.com/questions/56239/secure-connection-faile > > d-ocsp, there is a comment: > > > > "By the way, OCSP stapling can only staple info for one certificate. The > > browser will still have to contact your intermediate certificates' OCSP > > servers unless you've recently visited another website using the same > > ones. > > (There's an RFC for stapling multiple certs in progress.) - Matt > > Nordhoff" > > To me, this sounds reasonable. Shouldn't the ocsptool loop over the > > complete cert list and check each cert ? What do you think ? > > Indeed, that would be the right thing to do. If there is a patch for > that I'll apply it. > > For completeness there is also rfc6961, which allows for multiple OCSP > staples to > be included in the server's reply, but doesn't seem to be supported by > anyone. I have an implementation in some branch of gnutls, but as I > couldn't make interop > check with anyone, it is left out. I have a look at it tomorrow. Thanks for making clear. Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From INVALID.NOREPLY at gnu.org Thu Jan 15 20:58:01 2015 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Thu, 15 Jan 2015 19:58:01 +0000 Subject: [gnutls-devel] [sr #108724] Configure option to avoid building tools In-Reply-To: <20150115-003459.sv86557.48724@savannah.gnu.org> References: <20150111-132251.sv86557.94568@savannah.gnu.org> <20150112-115534.sv707.73467@savannah.gnu.org> <20150112-193412.sv0.50196@savannah.gnu.org> <20150112-193459.sv86557.80019@savannah.gnu.org> <20150112-235929.sv707.1807@savannah.gnu.org> <20150112-224625.sv86557.51576@savannah.gnu.org> <20150112-225831.sv86557.11533@savannah.gnu.org> <20150113-012902.sv707.57029@savannah.gnu.org> <20150112-234012.sv86557.420@savannah.gnu.org> <20150113-234935.sv707.17238@savannah.gnu.org> <20150113-215836.sv86557.88179@savannah.gnu.org> <20150115-000109.sv707.66091@savannah.gnu.org> <20150115-003459.sv86557.48724@savannah.gnu.org> Message-ID: <20150115-215801.sv707.72490@savannah.gnu.org> Follow-up Comment #12, sr #108724 (project gnutls): The attached file is exactly the same as before. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Thu Jan 15 22:15:25 2015 From: INVALID.NOREPLY at gnu.org (Luke Dashjr) Date: Thu, 15 Jan 2015 21:15:25 +0000 Subject: [gnutls-devel] [sr #108724] Configure option to avoid building tools In-Reply-To: <20150115-215801.sv707.72490@savannah.gnu.org> References: <20150111-132251.sv86557.94568@savannah.gnu.org> <20150112-115534.sv707.73467@savannah.gnu.org> <20150112-193412.sv0.50196@savannah.gnu.org> <20150112-193459.sv86557.80019@savannah.gnu.org> <20150112-235929.sv707.1807@savannah.gnu.org> <20150112-224625.sv86557.51576@savannah.gnu.org> <20150112-225831.sv86557.11533@savannah.gnu.org> <20150113-012902.sv707.57029@savannah.gnu.org> <20150112-234012.sv86557.420@savannah.gnu.org> <20150113-234935.sv707.17238@savannah.gnu.org> <20150113-215836.sv86557.88179@savannah.gnu.org> <20150115-000109.sv707.66091@savannah.gnu.org> <20150115-003459.sv86557.48724@savannah.gnu.org> <20150115-215801.sv707.72490@savannah.gnu.org> Message-ID: <20150115-211525.sv86557.56680@savannah.gnu.org> Follow-up Comment #13, sr #108724 (project gnutls): I just downloaded it from this page and it gave me the revised version. The only change was the "nono" you requested. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Fri Jan 16 09:28:18 2015 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Fri, 16 Jan 2015 08:28:18 +0000 Subject: [gnutls-devel] [sr #108724] Configure option to avoid building tools In-Reply-To: <20150115-211525.sv86557.56680@savannah.gnu.org> References: <20150111-132251.sv86557.94568@savannah.gnu.org> <20150112-115534.sv707.73467@savannah.gnu.org> <20150112-193412.sv0.50196@savannah.gnu.org> <20150112-193459.sv86557.80019@savannah.gnu.org> <20150112-235929.sv707.1807@savannah.gnu.org> <20150112-224625.sv86557.51576@savannah.gnu.org> <20150112-225831.sv86557.11533@savannah.gnu.org> <20150113-012902.sv707.57029@savannah.gnu.org> <20150112-234012.sv86557.420@savannah.gnu.org> <20150113-234935.sv707.17238@savannah.gnu.org> <20150113-215836.sv86557.88179@savannah.gnu.org> <20150115-000109.sv707.66091@savannah.gnu.org> <20150115-003459.sv86557.48724@savannah.gnu.org> <20150115-215801.sv707.72490@savannah.gnu.org> <20150115-211525.sv86557.56680@savannah.gnu.org> Message-ID: <20150116-102818.sv707.17852@savannah.gnu.org> Follow-up Comment #14, sr #108724 (project gnutls): I may have not been clear. I meant all the tests where two variables are used in combination. The "$enable_tools$enable_doc" != "nono" was an example. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From tim.ruehsen at gmx.de Fri Jan 16 13:27:25 2015 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Fri, 16 Jan 2015 13:27:25 +0100 Subject: [gnutls-devel] GnuTLS not working with AXA !? Message-ID: <1929900.YbxtXtvVb7@blitz-lx> Hi, while testing, I stumbled upon www.axa.co.uk. $ gnutls-cli -d3 -V www.axa.co.uk ... Processed 171 CA certificate(s). Resolving 'www.axa.co.uk'... Connecting to '163.156.208.179:443'... |<3>| ASSERT: gnutls_constate.c:586 |<3>| ASSERT: gnutls_buffers.c:1139 |<3>| ASSERT: gnutls_record.c:795 |<3>| ASSERT: gnutls_record.c:802 |<3>| ASSERT: gnutls_record.c:1322 |<3>| ASSERT: gnutls_buffers.c:1392 |<3>| ASSERT: gnutls_handshake.c:1428 |<3>| ASSERT: gnutls_handshake.c:2714 *** Fatal error: A TLS fatal alert has been received. *** Received alert [70]: Error in protocol version *** Handshake has failed GnuTLS error: A TLS fatal alert has been received. I also did try "NORMAL:%COMPAT", +VERS-SSL3.0 and some more with extensions enabled/disabled. Firefox/Iceweasel (OpenSSL I guess) do not have a problem. I am using GnuTLS 3.3.11. Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From nmav at gnutls.org Fri Jan 16 13:54:33 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 16 Jan 2015 13:54:33 +0100 Subject: [gnutls-devel] GnuTLS not working with AXA !? In-Reply-To: <1929900.YbxtXtvVb7@blitz-lx> References: <1929900.YbxtXtvVb7@blitz-lx> Message-ID: On Fri, Jan 16, 2015 at 1:27 PM, Tim Ruehsen wrote: > Hi, > while testing, I stumbled upon www.axa.co.uk. > $ gnutls-cli -d3 -V www.axa.co.uk It is one of the broken servers described in: http://lists.gnutls.org/pipermail/gnutls-help/2014-November/003673.html This server is also even more special since it also doesn't accept TLS 1.2 on the record version (thus using %LATEST_RECORD_VERSION hack breaks it too). The server's TLS implementation is designed to work only with fallback dance that browsers use. Anyway, for this type of servers I have modified gnutls 3.3.x branch to not use an SSL 3.0 record version, if SSL 3.0 is disabled. I don't see any other work around possible. regards, Nikos From INVALID.NOREPLY at gnu.org Fri Jan 16 15:14:59 2015 From: INVALID.NOREPLY at gnu.org (Luke Dashjr) Date: Fri, 16 Jan 2015 14:14:59 +0000 Subject: [gnutls-devel] [sr #108724] Configure option to avoid building tools In-Reply-To: <20150116-102818.sv707.17852@savannah.gnu.org> References: <20150111-132251.sv86557.94568@savannah.gnu.org> <20150112-115534.sv707.73467@savannah.gnu.org> <20150112-193412.sv0.50196@savannah.gnu.org> <20150112-193459.sv86557.80019@savannah.gnu.org> <20150112-235929.sv707.1807@savannah.gnu.org> <20150112-224625.sv86557.51576@savannah.gnu.org> <20150112-225831.sv86557.11533@savannah.gnu.org> <20150113-012902.sv707.57029@savannah.gnu.org> <20150112-234012.sv86557.420@savannah.gnu.org> <20150113-234935.sv707.17238@savannah.gnu.org> <20150113-215836.sv86557.88179@savannah.gnu.org> <20150115-000109.sv707.66091@savannah.gnu.org> <20150115-003459.sv86557.48724@savannah.gnu.org> <20150115-215801.sv707.72490@savannah.gnu.org> <20150115-211525.sv86557.56680@savannah.gnu.org> <20150116-102818.sv707.17852@savannah.gnu.org> Message-ID: <20150116-141459.sv86557.70773@savannah.gnu.org> Additional Item Attachment, sr #108724 (project gnutls): File name: 0001-Added-configure-option-disable-tools.patch Size:4 KB _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Fri Jan 16 16:03:02 2015 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Fri, 16 Jan 2015 15:03:02 +0000 Subject: [gnutls-devel] [sr #108724] Configure option to avoid building tools In-Reply-To: <20150116-141459.sv86557.70773@savannah.gnu.org> References: <20150111-132251.sv86557.94568@savannah.gnu.org> <20150112-115534.sv707.73467@savannah.gnu.org> <20150112-193412.sv0.50196@savannah.gnu.org> <20150112-193459.sv86557.80019@savannah.gnu.org> <20150112-235929.sv707.1807@savannah.gnu.org> <20150112-224625.sv86557.51576@savannah.gnu.org> <20150112-225831.sv86557.11533@savannah.gnu.org> <20150113-012902.sv707.57029@savannah.gnu.org> <20150112-234012.sv86557.420@savannah.gnu.org> <20150113-234935.sv707.17238@savannah.gnu.org> <20150113-215836.sv86557.88179@savannah.gnu.org> <20150115-000109.sv707.66091@savannah.gnu.org> <20150115-003459.sv86557.48724@savannah.gnu.org> <20150115-215801.sv707.72490@savannah.gnu.org> <20150115-211525.sv86557.56680@savannah.gnu.org> <20150116-102818.sv707.17852@savannah.gnu.org> <20150116-141459.sv86557.70773@savannah.gnu.org> Message-ID: <20150116-170302.sv707.37635@savannah.gnu.org> Update of sr #108724 (project gnutls): Status: None => Done Open/Closed: Open => Closed _______________________________________________________ Follow-up Comment #15: Thanks, applied in master. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From luke at dashjr.org Mon Jan 12 23:57:21 2015 From: luke at dashjr.org (Luke Dashjr) Date: Mon, 12 Jan 2015 22:57:21 +0000 Subject: [gnutls-devel] [PATCH] Added configure option --disable-tools Message-ID: <201501122257.22046.luke@dashjr.org> Developer's Certificate of Origin 1.1 By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Added-configure-option-disable-tools.patch Type: text/x-patch Size: 4583 bytes Desc: not available URL: From nmav at gnutls.org Sat Jan 17 09:19:48 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 17 Jan 2015 09:19:48 +0100 Subject: [gnutls-devel] gnutls 3.3.12 Message-ID: <1421482788.2029.3.camel@gnutls.org> Hello, I've just released gnutls 3.3.12. This is a bug-fix release on the current stable branch. It also fixes compatibility issues with servers which reject clients with an SSL 3.0 record version, which merely indicates the format of the record not the negotiated version. After this version GnuTLS will set TLS 1.0 as the record version number, unless only SSL 3.0 is enabled. * Version 3.3.12 (released 2015-01-17) ** libgnutls: When negotiating TLS use the lowest enabled version in the client hello, rather than the lowest supported. In addition, do not use SSL 3.0 as a version in the TLS record layer, unless SSL 3.0 is the only protocol supported. That addresses issues with servers that immediately drop the connection when the encounter SSL 3.0 as the record version number. See: http://lists.gnutls.org/pipermail/gnutls-help/2014-November/003673.html ** libgnutls: Corrected encoding and decoding of ANSI X9.62 parameters. ** libgnutls: Handle zero length plaintext for VIA PadLock functions. This solves a potential crash on AES encryption for small size plaintext. Patch by Matthias-Christian Ott. ** libgnutls: In DTLS don't combine multiple packets which exceed MTU. Reported by Andreas Schultz. https://savannah.gnu.org/support/?108715 ** libgnutls: In DTLS decode all handshake packets present in a record packet, in a single pass. Reported by Andreas Schultz. https://savannah.gnu.org/support/?108712 ** libgnutls: When importing a CA file with a PKCS #11 URL, simply import the certificates, if the URL specifies objects, rather than treating it as trust module. ** libgnutls: When importing a PKCS #11 URL and we know the type of object we are importing, don't require the object type in the URL. ** libgnutls: fixed openpgp authentication when gnutls_certificate_set_retrieve_function2 was used by the server. ** guile: Fix compilation on MinGW. Previously only the static version of the 'guile-gnutls-v-2' library would be built, preventing dynamic loading from Guile. ** guile: Fix harmless warning during compilation of gnutls.scm Initially reported at . ** certtool: --pubkey-info will also attempt to load a public key from stdin. ** gnutls-cli: Added --starttls-proto option. That allows to specify a protocol for starttls negotiation. ** API and ABI modifications: No changes since last version. Getting the Software ==================== GnuTLS may be downloaded directly from . A list of GnuTLS mirrors can be found at . Here are the XZ and LZIP compressed sources: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.12.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.12.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.12.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.12.tar.lz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From tim.ruehsen at gmx.de Sat Jan 17 14:55:24 2015 From: tim.ruehsen at gmx.de (Tim =?ISO-8859-1?Q?R=FChsen?=) Date: Sat, 17 Jan 2015 14:55:24 +0100 Subject: [gnutls-devel] [PATCH] OCSP check the whole cert chain In-Reply-To: References: <4350608.UCMoa1nDjP@blitz-lx> <3047578.e0qapIJ357@blitz-lx> Message-ID: <2024118.j4zEklUhuh@debian> Am Donnerstag, 15. Januar 2015, 16:53:22 schrieb Nikos Mavrogiannopoulos: > On Thu, Jan 15, 2015 at 4:18 PM, Tim Ruehsen wrote: > > Wow Nikos, that was fast ! Thank you. > > I'll try it out soon. > > Just a follow-up question regarding OCSP. > > Looking at > > http://security.stackexchange.com/questions/56239/secure-connection-faile > > d-ocsp, there is a comment: > > > > "By the way, OCSP stapling can only staple info for one certificate. The > > browser will still have to contact your intermediate certificates' OCSP > > servers unless you've recently visited another website using the same > > ones. > > (There's an RFC for stapling multiple certs in progress.) - Matt > > Nordhoff" > > To me, this sounds reasonable. Shouldn't the ocsptool loop over the > > complete cert list and check each cert ? What do you think ? > > Indeed, that would be the right thing to do. If there is a patch for > that I'll apply it. Hi Nikos, I made up a first patch to check the whole cert chain. Not sure what to do for e.g. www.google.com where the last cert in the chain is not verifiable via OCSP. Please feel free to amend anything you like. Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-OCSP-check-the-whole-cert-chain.patch Type: text/x-patch Size: 5070 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From tim.ruehsen at gmx.de Mon Jan 19 14:36:31 2015 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Mon, 19 Jan 2015 14:36:31 +0100 Subject: [gnutls-devel] OCSP / gnutls_ocsp_status_request_is_checked() Message-ID: <284338804.8SFZEVX0nV@blitz-lx> Hi, for caching and user information purposes I would like to see gnutls_ocsp_status_request_is_checked() (or a new function, see below) return three states: 1. no stapled OCSP response 2. cert is valid 3. cert has been revoked Since we have to check the whole cert chain (you already mentioned rfc 6961), I suggest a new function that returns an array of result codes, one for each cert in the chain. Similar to gnutls_certificate_get_peers(). Each result code with e.g. Notavail, Valid or Revoked. This approach would work with the current state (one stapled response) and with future implementations of rfc 6961 (without it, OCSP stapling seems totally incomplete). Maybe it's time to contact the Apache and Nginx people to think about rfc 6961? What do you think ? Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From nmav at gnutls.org Mon Jan 19 15:33:47 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 19 Jan 2015 15:33:47 +0100 Subject: [gnutls-devel] [PATCH] OCSP check the whole cert chain In-Reply-To: <2024118.j4zEklUhuh@debian> References: <4350608.UCMoa1nDjP@blitz-lx> <3047578.e0qapIJ357@blitz-lx> <2024118.j4zEklUhuh@debian> Message-ID: On Sat, Jan 17, 2015 at 2:55 PM, Tim R?hsen wrote: >> > (There's an RFC for stapling multiple certs in progress.) - Matt >> > Nordhoff" >> > To me, this sounds reasonable. Shouldn't the ocsptool loop over the >> > complete cert list and check each cert ? What do you think ? >> Indeed, that would be the right thing to do. If there is a patch for >> that I'll apply it. > Hi Nikos, > I made up a first patch to check the whole cert chain. > Not sure what to do for e.g. www.google.com where the last cert in the chain > is not verifiable via OCSP. Thank you. I've applied a modified patch, where this is skipped. With the updated patch, we check OCSP for the certificates we have information to use. For the others, we simply cannot check them. regards, Nikos From nmav at gnutls.org Mon Jan 19 15:49:24 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 19 Jan 2015 15:49:24 +0100 Subject: [gnutls-devel] OCSP / gnutls_ocsp_status_request_is_checked() In-Reply-To: <284338804.8SFZEVX0nV@blitz-lx> References: <284338804.8SFZEVX0nV@blitz-lx> Message-ID: On Mon, Jan 19, 2015 at 2:36 PM, Tim Ruehsen wrote: > Hi, > > for caching and user information purposes I would like to see > gnutls_ocsp_status_request_is_checked() (or a new function, see below) > return three states: > > 1. no stapled OCSP response > 2. cert is valid > 3. cert has been revoked Note that (2) and (3) you get already during the certificate_verify_peers() process. The gnutls_ocsp_status_request_is_checked() is to check for informative purposes whether the stapled OCSP response was taken into account in the certification. Since this gnutls_ocsp_status_request_is_checked() accepts flags, we could add a flag to modify its semantics if you think that some information is not yet available. > Since we have to check the whole cert chain (you already mentioned rfc 6961), > I suggest a new function that returns an array of result codes, one for each > cert in the chain. Similar to gnutls_certificate_get_peers(). Each result code > with e.g. Notavail, Valid or Revoked. > This approach would work with the current state (one stapled response) and > with future implementations of rfc 6961 (without it, OCSP stapling seems > totally incomplete). > Maybe it's time to contact the Apache and Nginx people to think about rfc > 6961? Well, I guess so. I've put in ocsp2 branch my experimental patch for gnutls supporting that: https://gitorious.org/gnutls/gnutls/commit/f24c5cdb73cf0e10cfe90d28e564e780b36c0142 It most probably doesn't apply as it now, and will require some tool support (to combine the multiple ocsp responses into a file). Not sure if I'll have time to complete it sometime soon. regards, Nikos From tim.ruehsen at gmx.de Mon Jan 19 17:06:46 2015 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Mon, 19 Jan 2015 17:06:46 +0100 Subject: [gnutls-devel] OCSP / gnutls_ocsp_status_request_is_checked() In-Reply-To: References: <284338804.8SFZEVX0nV@blitz-lx> Message-ID: <2194461.kEVaSqKx3H@blitz-lx> On Monday 19 January 2015 15:49:24 Nikos Mavrogiannopoulos wrote: > On Mon, Jan 19, 2015 at 2:36 PM, Tim Ruehsen wrote: > > Hi, > > > > for caching and user information purposes I would like to see > > gnutls_ocsp_status_request_is_checked() (or a new function, see below) > > return three states: > > > > 1. no stapled OCSP response > > 2. cert is valid > > 3. cert has been revoked > > Note that (2) and (3) you get already during the > certificate_verify_peers() process. The > gnutls_ocsp_status_request_is_checked() is to check for informative > purposes whether the stapled OCSP response was taken into account in > the certification. Since this gnutls_ocsp_status_request_is_checked() > accepts flags, we could add a flag to modify its semantics if you > think that some information is not yet available. Ahh, thanks. I didn't realize that GNUTLS_CERT_REVOKED is set via OCSP stapling. Just tested it - works fine ! That is what I needed. > > Since we have to check the whole cert chain (you already mentioned rfc > > 6961), I suggest a new function that returns an array of result codes, > > one for each cert in the chain. Similar to > > gnutls_certificate_get_peers(). Each result code with e.g. Notavail, > > Valid or Revoked. > > This approach would work with the current state (one stapled response) and > > with future implementations of rfc 6961 (without it, OCSP stapling seems > > totally incomplete). > > Maybe it's time to contact the Apache and Nginx people to think about rfc > > 6961? > > Well, I guess so. I've put in ocsp2 branch my experimental patch for > gnutls supporting that: > https://gitorious.org/gnutls/gnutls/commit/f24c5cdb73cf0e10cfe90d28e564e780b > 36c0142 It most probably doesn't apply as it now, and will require some tool > support (to combine the multiple ocsp responses into a file). Not sure if > I'll have time to complete it sometime soon. Apache is aware of the problem that RFC6961 addresses and mentions it the the docs. But it seems not implemented yet, neither in nginx. Ivan Ristic says in his book (http://blog.ivanristic.com/2014/02/bulletproof-early-access-now-available.html): "... this improved version is not well supported in either client or server software" I found a few posts from people requesting and/or waiting for multi-stapling to come. Sounds like a hen/egg problem to me. Since many web sites nowadays use intermediate CA certs, multi-stapling will have the same benefits as the introduction of OCSP stapling. I don't quite understand "will require some tool support". How can I help ? Let gnutls-cli use the ocsp2 code (e.g. new option --ocsp-multi) ? With this, the apache and nginx people have a tool for testing and might start implementing multi-stapling on the server side. Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From nmav at gnutls.org Mon Jan 19 18:46:44 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 19 Jan 2015 18:46:44 +0100 Subject: [gnutls-devel] OCSP / gnutls_ocsp_status_request_is_checked() In-Reply-To: <2194461.kEVaSqKx3H@blitz-lx> References: <284338804.8SFZEVX0nV@blitz-lx> <2194461.kEVaSqKx3H@blitz-lx> Message-ID: <1421689604.2036.1.camel@gnutls.org> On Mon, 2015-01-19 at 17:06 +0100, Tim Ruehsen wrote: > Sounds like a hen/egg problem to me. > Since many web sites nowadays use intermediate CA certs, multi-stapling will > have the same benefits as the introduction of OCSP stapling. > I don't quite understand "will require some tool support". How can I help ? > Let gnutls-cli use the ocsp2 code (e.g. new option --ocsp-multi) ? I see that there are files missing from my branch, I hope that I still have them somewhere. However, my concern when I was developing it, was that there is no standard format to store multiple ocsp responses. So I made a quick hack with a binary format which will require minimal parsing by the sending server. However, ocsptool doesn't generate that format, nor there is a way to easily combine multiple responses into that. That's what is currently missing. The format is the same as OCSPResponseList in the wire of rfc6961, plus a header GNUTLS_OCSP_MULTI_MAGIC. opaque OCSPResponse<0..2^24-1>; #each response is prefixed with an 24-bit integer showing length struct { OCSPResponse ocsp_response_list<1..2^24-1>; } OCSPResponseList; # the list has a 24-bit integer showing it's length in bytes, and consists of multiple OCSPResponse structs. This was the missing part. regards, Nikos From nmav at gnutls.org Tue Jan 20 09:48:10 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 20 Jan 2015 09:48:10 +0100 Subject: [gnutls-devel] OCSP / gnutls_ocsp_status_request_is_checked() In-Reply-To: <1421689604.2036.1.camel@gnutls.org> References: <284338804.8SFZEVX0nV@blitz-lx> <2194461.kEVaSqKx3H@blitz-lx> <1421689604.2036.1.camel@gnutls.org> Message-ID: On Mon, Jan 19, 2015 at 6:46 PM, Nikos Mavrogiannopoulos wrote: > I see that there are files missing from my branch, I hope that I still > have them somewhere. However, my concern when I was developing it, was > that there is no standard format to store multiple ocsp responses. So I > made a quick hack with a binary format which will require minimal > parsing by the sending server. However, ocsptool doesn't generate that > format, nor there is a way to easily combine multiple responses into > that. That's what is currently missing. The missing files are now committed in the ocsp2 branch. regards, Nikos From coyo at darkdna.net Sat Jan 24 20:34:46 2015 From: coyo at darkdna.net (Coyo) Date: Sat, 24 Jan 2015 13:34:46 -0600 Subject: [gnutls-devel] OpenSSL Library Call Redirection, OpenPGP, DANE Message-ID: <54C3F3D6.7060202@darkdna.net> I have three separate questions, and I apologize in advance for posting to multiple newsgroups and mailservs. But I was taught two things by some very smart individuals: 1) The only dumb question is an unasked one, and 2) When dealing with serious cryptography, do not guess, ask an actual cryptographer. So I have a few separate but related questions: Is is possible to use OpenPGP in DANE? What do I need to do this? Can I redirect applications that rely specifically on OpenSSL to use NSS or GnuTLS instead somehow? My understanding of external library calls is severely limited, but my understanding is that there's such a thing as DLL/SO injection, which renames the library and then places an imposter library in its place so that calls to that library are intercepted, and either handled by the imposter or transparently forwarded to the real library. This happens all of the time in the PC gaming world, and is a critical tool in cheating on multiplayer games. It is a method to manipulate the game client's internal binary logic. It follows logically that such a technique SHOULD be possible with OpenSSL, NSS and GnuTLS. It may be that there are wrappers or special programs or tools that already do this, but I am unaware of any that work universally. Are calls to OpenSSL standardized in some what? Could a simple symlink work? DANE is a fascinating system, and some applications I am interested in optionally use DANE to verify the authenticity of certificates/keys. Is it possible to use DANE locally to indirectly use GnuTLS or NSS as backend cryptographic libraries? Does PowerDNS or any of the common DANE-supporting nameservers explicitly support cryptographic libraries other than OpenSSL? I made several attempts to divine this knowledge, and was unsucessful. Perhaps my Google-fu is not enough. I fail to grok how I should this. While applications like Pidgin use NSS, which is refreshing, most applications I take an interest in specifically link to OpenSSL, rather than being written as cryptographic library agnostic. As a mere padawan, I do not know what I can do about this. The project I have in mind uses PostFix and INN on a private LAN/VPN to exchange files amongst a group. This group is a set of local neighborhoods connected by explicit links. These links use CJDNS for IP addresss allocation and NameCoin for name allocation. However, NameCoin does not necessarily provide DANE emulation. NameCoin does support arbitrary extensions, because it can use any prefix:key=value binding by "spending" a NameCoin. This should be trivial enough to write with a simple Bash Shell Script. I am competent enough to write Bash Shell Scripts. However, I am too smart to attempt mucking about with cryptographic libraries without consulting a cryptography guru. I realize I could somehow get PowerDNS to serve NameCoin .bit records using the local DNS cache or perhaps a script, but I'm not sure how to inject OpenPGP certs into DANE records. I do know I can bind OpenPGP keys into NameCoin .bit addresses in the same manner as regular DNS records, but I'm not sure if this is cryptographically sound. Thus why I'm asking people who DO know what they are doing. So by manually posting OpenPGP keys along with names into .bit records, then using a PowerDNS authoritative server to serve the .bit records from a local DNS cache (somehow), i could provide DANE records to bind .bit names to CJDNS IPv6 addresses. This would provide a completely decentralized network, both at the IP addressspace and DNS namespace levels, IF it works. However, some of the servers I'd host on this infrastructure relies specifically on OpenSSL, and I suspect OpenSSL does not support verifying keys using OpenPGP, and perhaps not DANE. I'm honestly not sure. But INN and PostFix would have problems with server-to-server TLS links if the certs don't validate. I really want to use TLS, even though CJDNS does use NACL cryptography for its peering links. I don't like relying on only one cryptographic library for security. I want both underlying NACL cryptography and TLS cryptography to help protect sensitive data. But the idea of using NameCoin + CJDNS -> PowerDNS + GnuPG + NSS/GnuTLS -> Nginx + INN + PostFix + ... stack seems a little precarious to me. Thank you very much for you patience, time and attention. Thank you very much in advance for any help, advice, instruction, protips, hints or references you may give me. Thank you. -- Alex Maurin From mrsam at courier-mta.com Sat Jan 24 23:07:17 2015 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Sat, 24 Jan 2015 17:07:17 -0500 Subject: [gnutls-devel] OpenSSL Library Call Redirection, OpenPGP, DANE References: <54C3F3D6.7060202@darkdna.net> Message-ID: Coyo writes: > My understanding of external library calls is severely limited, but my > understanding is that there's such a thing as DLL/SO injection, which > renames the library and then places an imposter library in its place so > that calls to that library are intercepted, and either handled by the > imposter or transparently forwarded to the real library. > > This happens all of the time in the PC gaming world, and is a critical > tool in cheating on multiplayer games. It is a method to manipulate the > game client's internal binary logic. > > It follows logically that such a technique SHOULD be possible with > OpenSSL, NSS and GnuTLS. Sure it's theoretically possible. Now, the only thing needs to happen is for someone to write something like this. > It may be that there are wrappers or special > programs or tools that already do this, but I am unaware of any that > work universally. > > Are calls to OpenSSL standardized in some what? Could a simple symlink work? No. OpenSSL and GnuTLS are completely different APIs. They work in completely different manner, in countless different ways. You can't just substitute one library for another. I've written client code that uses both OpenSSL and GnuTLS. What you describe is theoretically possible, of course. But someone would have to write a lot of code to implement a translation layer between OpenSSL and GnuTLS. I hazily remember hearing about some light translation layer somewhere, that reimplements a very tiny subset of the OpenSSL API using GnuTLS, but code had to be explicitly recompiled against it. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From coyo at darkdna.net Sun Jan 25 01:27:43 2015 From: coyo at darkdna.net (Coyo) Date: Sat, 24 Jan 2015 18:27:43 -0600 Subject: [gnutls-devel] OpenSSL Library Call Redirection, OpenPGP, DANE In-Reply-To: References: <54C3F3D6.7060202@darkdna.net> Message-ID: <54C4387F.3070901@darkdna.net> On 1/24/2015 4:07 PM, Sam Varshavchik wrote: > No. > > OpenSSL and GnuTLS are completely different APIs. They work in > completely different manner, in countless different ways. You can't just > substitute one library for another. > > I've written client code that uses both OpenSSL and GnuTLS. What you > describe is theoretically possible, of course. But someone would have to > write a lot of code to implement a translation layer between OpenSSL and > GnuTLS. I hazily remember hearing about some light translation layer > somewhere, that reimplements a very tiny subset of the OpenSSL API using > GnuTLS, but code had to be explicitly recompiled against it. THANK YOU SO MUCH!!!! That really helps out a lot, you have no idea how much! You saved me an immense amount of time and effort, thank you!