From amirouche at hypermove.net Mon May 1 22:26:30 2017 From: amirouche at hypermove.net (Amirouche) Date: Mon, 1 May 2017 22:26:30 +0200 Subject: [gnutls-help] IMAP SSL Connection using Guile Message-ID: <1451d1cc-5642-c08b-ded2-2bbb0565ca61@hypermove.net> H?llo I am trying to connect to an imap server using SSL but it fails. The program does indeed connect to the remote server, but when I try to read on the port it blocks until the connection is closed by the remote host. Everything works fine using gnutls-cli. The version reported by gnutls-cli is 3.5.8 Here is my code: --------->8--------->8--------->8--------->8--------->8--------->8--------->8--------- (define-module (imap)) (use-modules (gnutls)) (use-modules (ice-9 rdelim)) (set-log-level! 10) (set-log-procedure! pk) (define tls-wrap (@@ (web client) tls-wrap)) (define (connect-to-server host port) (let ((addrinfo (car (getaddrinfo host (number->string port))))) (let ((port (socket (addrinfo:fam addrinfo) SOCK_STREAM IPPROTO_IP))) ;; Disable Nagle's algorithm. We buffer ourselves. (setsockopt port IPPROTO_TCP TCP_NODELAY 1) (setvbuf port 'block 1024) (connect port (addrinfo:addr addrinfo)) port))) (define (make-imap-port host port) (let ((port (connect-to-server host port))) (tls-wrap port host))) (define port (make-imap-port "imap.gmail.com" 993)) (pk 'out (read-line port)) --------->8--------->8--------->8--------->8--------->8--------->8--------->8--------->8--------- Here is the definition of tls-wrap in guile 2.2: --------->8--------->8--------->8--------->8--------->8--------->8--------->8--------->8--------- (define (tls-wrap port server) "Return PORT wrapped in a TLS connection to SERVER. SERVER must be a DNS host name without trailing dot." (define (log level str) (format (current-error-port) "gnutls: [~a|~a] ~a" (getpid) level str)) (ensure-gnutls) (let ((session (make-session connection-end/client))) ;; Some servers such as 'cloud.github.com' require the client to support ;; the 'SERVER NAME' extension. However, 'set-session-server-name!' is ;; not available in older GnuTLS releases. See ;; for details. (if (module-defined? (force gnutls-module) 'set-session-server-name!) (set-session-server-name! session server-name-type/dns server) (format (current-error-port) "warning: TLS 'SERVER NAME' extension not supported~%")) (set-session-transport-fd! session (fileno port)) (set-session-default-priority! session) ;; The "%COMPAT" bit allows us to work around firewall issues (info ;; "(gnutls) Priority Strings"); see . ;; Explicitly disable SSLv3, which is insecure: ;; . (set-session-priorities! session "NORMAL:%COMPAT:-VERS-SSL3.0") (set-session-credentials! session (make-certificate-credentials)) ;; Uncomment the following lines in case of debugging emergency. ;;(set-log-level! 10) ;;(set-log-procedure! log) (handshake session) (let ((record (session-record-port session))) (define (read! bv start count) (define read-bv (get-bytevector-n record count)) (if (eof-object? read-bv) 0 ; read! returns 0 on eof-object (let ((read-bv-len (bytevector-length read-bv))) (bytevector-copy! read-bv 0 bv start read-bv-len) read-bv-len))) (define (write! bv start count) (put-bytevector record bv start count) count) (define (get-position) (rnrs-ports:port-position record)) (define (set-position! new-position) (rnrs-ports:set-port-position! record new-position)) (define (close) (unless (port-closed? port) (close-port port)) (unless (port-closed? record) (close-port record))) (make-custom-binary-input/output-port "gnutls wrapped port" read! write! get-position set-position! close)))) --------->8--------->8--------->8--------->8--------->8--------->8--------->8--------->8--------- At last, here is the debug output I have: --------->8--------->8--------->8--------->8--------->8--------->8--------->8--------->8--------- ;;; (5 "REC[0x1bcef00]: Allocating epoch #0\n") ;;; (3 "ASSERT: constate.c[_gnutls_epoch_get]:600\n") ;;; (5 "REC[0x1bcef00]: Allocating epoch #1\n") ;;; (4 "HSK[0x1bcef00]: Adv. version: 3.3\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_AES_256_GCM_SHA384 (C0.2C)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_CAMELLIA_256_GCM_SHA384 (C0.87)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_CHACHA20_POLY1305 (CC.A9)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_AES_256_CCM (C0.AD)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_AES_256_CBC_SHA1 (C0.0A)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_AES_256_CBC_SHA384 (C0.24)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_CAMELLIA_256_CBC_SHA384 (C0.73)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_AES_128_GCM_SHA256 (C0.2B)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_CAMELLIA_128_GCM_SHA256 (C0.86)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_AES_128_CCM (C0.AC)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_AES_128_CBC_SHA1 (C0.09)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_AES_128_CBC_SHA256 (C0.23)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_CAMELLIA_128_CBC_SHA256 (C0.72)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_3DES_EDE_CBC_SHA1 (C0.08)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_AES_256_GCM_SHA384 (C0.30)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_CAMELLIA_256_GCM_SHA384 (C0.8B)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_CHACHA20_POLY1305 (CC.A8)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_AES_256_CBC_SHA1 (C0.14)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_AES_256_CBC_SHA384 (C0.28)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_CAMELLIA_256_CBC_SHA384 (C0.77)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_AES_128_GCM_SHA256 (C0.2F)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_CAMELLIA_128_GCM_SHA256 (C0.8A)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_AES_128_CBC_SHA1 (C0.13)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_AES_128_CBC_SHA256 (C0.27)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_CAMELLIA_128_CBC_SHA256 (C0.76)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_3DES_EDE_CBC_SHA1 (C0.12)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_RSA_AES_256_GCM_SHA384 (00.9D)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_RSA_CAMELLIA_256_GCM_SHA384 (C0.7B)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_RSA_AES_256_CCM (C0.9D)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_RSA_AES_256_CBC_SHA1 (00.35)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_RSA_AES_256_CBC_SHA256 (00.3D)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_RSA_CAMELLIA_256_CBC_SHA1 (00.84)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_RSA_CAMELLIA_256_CBC_SHA256 (00.C0)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_RSA_AES_128_GCM_SHA256 (00.9C)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_RSA_CAMELLIA_128_GCM_SHA256 (C0.7A)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_RSA_AES_128_CCM (C0.9C)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_RSA_AES_128_CBC_SHA1 (00.2F)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_RSA_AES_128_CBC_SHA256 (00.3C)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_RSA_CAMELLIA_128_CBC_SHA1 (00.41)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_RSA_CAMELLIA_128_CBC_SHA256 (00.BA)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_RSA_3DES_EDE_CBC_SHA1 (00.0A)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_DHE_RSA_AES_256_GCM_SHA384 (00.9F)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_DHE_RSA_CAMELLIA_256_GCM_SHA384 (C0.7D)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_DHE_RSA_CHACHA20_POLY1305 (CC.AA)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_DHE_RSA_AES_256_CCM (C0.9F)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_DHE_RSA_AES_256_CBC_SHA1 (00.39)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_DHE_RSA_AES_256_CBC_SHA256 (00.6B)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_DHE_RSA_CAMELLIA_256_CBC_SHA1 (00.88)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_DHE_RSA_CAMELLIA_256_CBC_SHA256 (00.C4)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_DHE_RSA_AES_128_GCM_SHA256 (00.9E)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_DHE_RSA_CAMELLIA_128_GCM_SHA256 (C0.7C)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_DHE_RSA_AES_128_CCM (C0.9E)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_DHE_RSA_AES_128_CBC_SHA1 (00.33)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_DHE_RSA_AES_128_CBC_SHA256 (00.67)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_DHE_RSA_CAMELLIA_128_CBC_SHA1 (00.45)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_DHE_RSA_CAMELLIA_128_CBC_SHA256 (00.BE)\n") ;;; (4 "HSK[0x1bcef00]: Keeping ciphersuite: GNUTLS_DHE_RSA_3DES_EDE_CBC_SHA1 (00.16)\n") ;;; (4 "EXT[0x1bcef00]: Sending extension OCSP Status Request (5 bytes)\n") ;;; (2 "HSK[0x1bcef00]: sent server name: 'imap.gmail.com'\n") ;;; (4 "EXT[0x1bcef00]: Sending extension Server Name Indication (19 bytes)\n") ;;; (4 "EXT[0x1bcef00]: Sending extension Safe Renegotiation (1 bytes)\n") ;;; (4 "EXT[0x1bcef00]: Sending extension Session Ticket (0 bytes)\n") ;;; (4 "EXT[0x1bcef00]: Sending extension Supported curves (12 bytes)\n") ;;; (4 "EXT[0x1bcef00]: Sending extension Supported ECC Point Formats (2 bytes)\n") ;;; (4 "EXT[0x1bcef00]: sent signature algo (4.1) RSA-SHA256\n") ;;; (4 "EXT[0x1bcef00]: sent signature algo (4.3) ECDSA-SHA256\n") ;;; (4 "EXT[0x1bcef00]: sent signature algo (5.1) RSA-SHA384\n") ;;; (4 "EXT[0x1bcef00]: sent signature algo (5.3) ECDSA-SHA384\n") ;;; (4 "EXT[0x1bcef00]: sent signature algo (6.1) RSA-SHA512\n") ;;; (4 "EXT[0x1bcef00]: sent signature algo (6.3) ECDSA-SHA512\n") ;;; (4 "EXT[0x1bcef00]: sent signature algo (3.1) RSA-SHA224\n") ;;; (4 "EXT[0x1bcef00]: sent signature algo (3.3) ECDSA-SHA224\n") ;;; (4 "EXT[0x1bcef00]: sent signature algo (2.1) RSA-SHA1\n") ;;; (4 "EXT[0x1bcef00]: sent signature algo (2.3) ECDSA-SHA1\n") ;;; (4 "EXT[0x1bcef00]: Sending extension Signature Algorithms (22 bytes)\n") ;;; (4 "HSK[0x1bcef00]: CLIENT HELLO was queued [248 bytes]\n") ;;; (5 "REC[0x1bcef00]: Preparing Packet Handshake(22) with length: 248 and min pad: 0\n") ;;; (9 "ENC[0x1bcef00]: cipher: NULL, MAC: MAC-NULL, Epoch: 0\n") ;;; (5 "REC[0x1bcef00]: Sent Packet[1] Handshake(22) in epoch 0 and length: 253\n") ;;; (3 "ASSERT: buffers.c[get_last_packet]:1159\n") ;;; (10 "READ: Got 5 bytes from 0x7\n") ;;; (10 "READ: read 5 bytes from 0x7\n") ;;; (10 "RB: Have 0 bytes into buffer. Adding 5 bytes.\n") ;;; (10 "RB: Requested 5 bytes\n") ;;; (5 "REC[0x1bcef00]: SSL 3.3 Handshake packet received. Epoch 0, length: 59\n") ;;; (5 "REC[0x1bcef00]: Expected Packet Handshake(22)\n") ;;; (5 "REC[0x1bcef00]: Received Packet Handshake(22) with length: 59\n") ;;; (10 "READ: Got 59 bytes from 0x7\n") ;;; (10 "READ: read 59 bytes from 0x7\n") ;;; (10 "RB: Have 5 bytes into buffer. Adding 59 bytes.\n") ;;; (10 "RB: Requested 64 bytes\n") ;;; (5 "REC[0x1bcef00]: Decrypted Packet[0] Handshake(22) with length: 59\n") ;;; (4 "HSK[0x1bcef00]: SERVER HELLO (2) was received. Length 55[55], frag offset 0, frag length: 55, sequence: 0\n") ;;; (4 "HSK[0x1bcef00]: Server's version: 3.3\n") ;;; (4 "HSK[0x1bcef00]: SessionID length: 0\n") ;;; (4 "HSK[0x1bcef00]: SessionID: cc\n") ;;; (4 "HSK[0x1bcef00]: Selected cipher suite: ECDHE_RSA_CHACHA20_POLY1305\n") ;;; (4 "HSK[0x1bcef00]: Selected compression method: NULL (0)\n") ;;; (4 "EXT[0x1bcef00]: Parsing extension 'Safe Renegotiation/65281' (1 bytes)\n") ;;; (4 "EXT[0x1bcef00]: Parsing extension 'Session Ticket/35' (0 bytes)\n") ;;; (4 "EXT[0x1bcef00]: Parsing extension 'Supported ECC Point Formats/11' (2 bytes)\n") ;;; (4 "HSK[0x1bcef00]: Safe renegotiation succeeded\n") ;;; (3 "ASSERT: buffers.c[get_last_packet]:1159\n") ;;; (10 "READ: Got 5 bytes from 0x7\n") ;;; (10 "READ: read 5 bytes from 0x7\n") ;;; (10 "RB: Have 0 bytes into buffer. Adding 5 bytes.\n") ;;; (10 "RB: Requested 5 bytes\n") ;;; (5 "REC[0x1bcef00]: SSL 3.3 Handshake packet received. Epoch 0, length: 3081\n") ;;; (5 "REC[0x1bcef00]: Expected Packet Handshake(22)\n") ;;; (5 "REC[0x1bcef00]: Received Packet Handshake(22) with length: 3081\n") ;;; (10 "READ: Got 1139 bytes from 0x7\n") ;;; (10 "READ: Got 1208 bytes from 0x7\n") ;;; (10 "READ: Got 734 bytes from 0x7\n") ;;; (10 "READ: read 3081 bytes from 0x7\n") ;;; (10 "RB: Have 5 bytes into buffer. Adding 3081 bytes.\n") ;;; (10 "RB: Requested 3086 bytes\n") ;;; (5 "REC[0x1bcef00]: Decrypted Packet[1] Handshake(22) with length: 3081\n") ;;; (4 "HSK[0x1bcef00]: CERTIFICATE (11) was received. Length 3077[3077], frag offset 0, frag length: 3077, sequence: 0\n") ;;; (3 "ASSERT: extensions.c[_gnutls_get_extension]:65\n") ;;; (3 "ASSERT: buffers.c[get_last_packet]:1159\n") ;;; (10 "READ: Got 5 bytes from 0x7\n") ;;; (10 "READ: read 5 bytes from 0x7\n") ;;; (10 "RB: Have 0 bytes into buffer. Adding 5 bytes.\n") ;;; (10 "RB: Requested 5 bytes\n") ;;; (5 "REC[0x1bcef00]: SSL 3.3 Handshake packet received. Epoch 0, length: 333\n") ;;; (5 "REC[0x1bcef00]: Expected Packet Handshake(22)\n") ;;; (5 "REC[0x1bcef00]: Received Packet Handshake(22) with length: 333\n") ;;; (10 "READ: Got 333 bytes from 0x7\n") ;;; (10 "READ: read 333 bytes from 0x7\n") ;;; (10 "RB: Have 5 bytes into buffer. Adding 333 bytes.\n") ;;; (10 "RB: Requested 338 bytes\n") ;;; (5 "REC[0x1bcef00]: Decrypted Packet[2] Handshake(22) with length: 333\n") ;;; (4 "HSK[0x1bcef00]: SERVER KEY EXCHANGE (12) was received. Length 329[329], frag offset 0, frag length: 329, sequence: 0\n") ;;; (2 "received curve SECP256R1\n") ;;; (4 "HSK[0x1bcef00]: Selected ECC curve SECP256R1 (2)\n") ;;; (3 "ASSERT: extensions.c[_gnutls_get_extension]:65\n") ;;; (4 "HSK[0x1bcef00]: verify handshake data: using RSA-SHA256\n") ;;; (3 "ASSERT: buffers.c[get_last_packet]:1159\n") ;;; (10 "READ: Got 5 bytes from 0x7\n") ;;; (10 "READ: read 5 bytes from 0x7\n") ;;; (10 "RB: Have 0 bytes into buffer. Adding 5 bytes.\n") ;;; (10 "RB: Requested 5 bytes\n") ;;; (5 "REC[0x1bcef00]: SSL 3.3 Handshake packet received. Epoch 0, length: 4\n") ;;; (5 "REC[0x1bcef00]: Expected Packet Handshake(22)\n") ;;; (5 "REC[0x1bcef00]: Received Packet Handshake(22) with length: 4\n") ;;; (10 "READ: Got 4 bytes from 0x7\n") ;;; (10 "READ: read 4 bytes from 0x7\n") ;;; (10 "RB: Have 5 bytes into buffer. Adding 4 bytes.\n") ;;; (10 "RB: Requested 9 bytes\n") ;;; (5 "REC[0x1bcef00]: Decrypted Packet[3] Handshake(22) with length: 4\n") ;;; (4 "HSK[0x1bcef00]: SERVER HELLO DONE (14) was received. Length 0[0], frag offset 0, frag length: 1, sequence: 0\n") ;;; (3 "ASSERT: buffers.c[get_last_packet]:1150\n") ;;; (3 "ASSERT: buffers.c[_gnutls_handshake_io_recv_int]:1379\n") ;;; (4 "HSK[0x1bcef00]: CLIENT KEY EXCHANGE was queued [70 bytes]\n") ;;; (4 "REC[0x1bcef00]: Sent ChangeCipherSpec\n") ;;; (9 "INT: PREMASTER SECRET[32]: 57b1d15927cf86d5a188845c5f3b91346da69a39de9ebaad9039ee6e7adce1c0\n") ;;; (9 "INT: CLIENT RANDOM[32]: 590612762d4f41311c6025cee173974704dc319a59b93aeeeb9a504356d147c5\n") ;;; (9 "INT: SERVER RANDOM[32]: 59061208083e7cef11d8f506f6284a7eb121c7dc28f41b01628843c5fcbfbf6c\n") ;;; (9 "INT: MASTER SECRET: 6ee6c108de1ef8085719a6b210f77f082842890f32637359d3a2c0ddb7dc7f2405672c1595b12b8de7ab64167669273b\n") ;;; (5 "REC[0x1bcef00]: Initializing epoch #1\n") ;;; (9 "INT: KEY BLOCK[88]: 2191dfbf92877090f07f26e3a012adb27481fee6f93dfde28ffa73c3b6050842\n") ;;; (9 "INT: CLIENT WRITE KEY [32]: 2191dfbf92877090f07f26e3a012adb27481fee6f93dfde28ffa73c3b6050842\n") ;;; (9 "INT: SERVER WRITE KEY [32]: 8cae979022a5925a1d87ff60ca438df85ba9bf0ab23fd748c8c8c4fc28f5024e\n") ;;; (9 "INT: CLIENT WRITE IV [12]: 4112d45c19b24a97e3777ef9\n") ;;; (9 "INT: SERVER WRITE IV [12]: d3c5e030e2354a4a11898074\n") ;;; (5 "REC[0x1bcef00]: Epoch #1 ready\n") ;;; (4 "HSK[0x1bcef00]: Cipher Suite: ECDHE_RSA_CHACHA20_POLY1305\n") ;;; (4 "HSK[0x1bcef00]: Initializing internal [write] cipher sessions\n") ;;; (4 "HSK[0x1bcef00]: recording tls-unique CB (send)\n") ;;; (4 "HSK[0x1bcef00]: FINISHED was queued [16 bytes]\n") ;;; (5 "REC[0x1bcef00]: Preparing Packet Handshake(22) with length: 70 and min pad: 0\n") ;;; (9 "ENC[0x1bcef00]: cipher: NULL, MAC: MAC-NULL, Epoch: 0\n") ;;; (5 "REC[0x1bcef00]: Sent Packet[2] Handshake(22) in epoch 0 and length: 75\n") ;;; (5 "REC[0x1bcef00]: Preparing Packet ChangeCipherSpec(20) with length: 1 and min pad: 0\n") ;;; (9 "ENC[0x1bcef00]: cipher: NULL, MAC: MAC-NULL, Epoch: 0\n") ;;; (5 "REC[0x1bcef00]: Sent Packet[3] ChangeCipherSpec(20) in epoch 0 and length: 6\n") ;;; (5 "REC[0x1bcef00]: Preparing Packet Handshake(22) with length: 16 and min pad: 0\n") ;;; (9 "ENC[0x1bcef00]: cipher: CHACHA20-POLY1305, MAC: AEAD, Epoch: 1\n") ;;; (5 "REC[0x1bcef00]: Sent Packet[1] Handshake(22) in epoch 1 and length: 37\n") ;;; (3 "ASSERT: buffers.c[get_last_packet]:1159\n") ;;; (10 "READ: Got 5 bytes from 0x7\n") ;;; (10 "READ: read 5 bytes from 0x7\n") ;;; (10 "RB: Have 0 bytes into buffer. Adding 5 bytes.\n") ;;; (10 "RB: Requested 5 bytes\n") ;;; (5 "REC[0x1bcef00]: SSL 3.3 Handshake packet received. Epoch 0, length: 190\n") ;;; (5 "REC[0x1bcef00]: Expected Packet Handshake(22)\n") ;;; (5 "REC[0x1bcef00]: Received Packet Handshake(22) with length: 190\n") ;;; (10 "READ: Got 190 bytes from 0x7\n") ;;; (10 "READ: read 190 bytes from 0x7\n") ;;; (10 "RB: Have 5 bytes into buffer. Adding 190 bytes.\n") ;;; (10 "RB: Requested 195 bytes\n") ;;; (5 "REC[0x1bcef00]: Decrypted Packet[4] Handshake(22) with length: 190\n") ;;; (4 "HSK[0x1bcef00]: NEW SESSION TICKET (4) was received. Length 186[186], frag offset 0, frag length: 186, sequence: 0\n") ;;; (10 "READ: Got 5 bytes from 0x7\n") ;;; (10 "READ: read 5 bytes from 0x7\n") ;;; (10 "RB: Have 0 bytes into buffer. Adding 5 bytes.\n") ;;; (10 "RB: Requested 5 bytes\n") ;;; (5 "REC[0x1bcef00]: SSL 3.3 ChangeCipherSpec packet received. Epoch 0, length: 1\n") ;;; (5 "REC[0x1bcef00]: Expected Packet ChangeCipherSpec(20)\n") ;;; (5 "REC[0x1bcef00]: Received Packet ChangeCipherSpec(20) with length: 1\n") ;;; (10 "READ: Got 1 bytes from 0x7\n") ;;; (10 "READ: read 1 bytes from 0x7\n") ;;; (10 "RB: Have 5 bytes into buffer. Adding 1 bytes.\n") ;;; (10 "RB: Requested 6 bytes\n") ;;; (5 "REC[0x1bcef00]: Decrypted Packet[5] ChangeCipherSpec(20) with length: 1\n") ;;; (4 "HSK[0x1bcef00]: Cipher Suite: ECDHE_RSA_CHACHA20_POLY1305\n") ;;; (3 "ASSERT: buffers.c[get_last_packet]:1159\n") ;;; (10 "READ: Got 5 bytes from 0x7\n") ;;; (10 "READ: read 5 bytes from 0x7\n") ;;; (10 "RB: Have 0 bytes into buffer. Adding 5 bytes.\n") ;;; (10 "RB: Requested 5 bytes\n") ;;; (5 "REC[0x1bcef00]: SSL 3.3 Handshake packet received. Epoch 0, length: 32\n") ;;; (5 "REC[0x1bcef00]: Expected Packet Handshake(22)\n") ;;; (5 "REC[0x1bcef00]: Received Packet Handshake(22) with length: 32\n") ;;; (10 "READ: Got 32 bytes from 0x7\n") ;;; (10 "READ: read 32 bytes from 0x7\n") ;;; (10 "RB: Have 5 bytes into buffer. Adding 32 bytes.\n") ;;; (10 "RB: Requested 37 bytes\n") ;;; (5 "REC[0x1bcef00]: Decrypted Packet[0] Handshake(22) with length: 16\n") ;;; (4 "HSK[0x1bcef00]: FINISHED (20) was received. Length 12[12], frag offset 0, frag length: 12, sequence: 0\n") ;;; (5 "REC[0x1bcef00]: Start of epoch cleanup\n") ;;; (5 "REC[0x1bcef00]: Epoch #0 freed\n") ;;; (5 "REC[0x1bcef00]: End of epoch cleanup\n") ;;; (10 "READ: Got 5 bytes from 0x7\n") ;;; (10 "READ: read 5 bytes from 0x7\n") ;;; (10 "RB: Have 0 bytes into buffer. Adding 5 bytes.\n") ;;; (10 "RB: Requested 5 bytes\n") ;;; (5 "REC[0x1bcef00]: SSL 3.3 Application Data packet received. Epoch 0, length: 109\n") ;;; (5 "REC[0x1bcef00]: Expected Packet Application Data(23)\n") ;;; (5 "REC[0x1bcef00]: Received Packet Application Data(23) with length: 109\n") ;;; (10 "READ: Got 109 bytes from 0x7\n") ;;; (10 "READ: read 109 bytes from 0x7\n") ;;; (10 "RB: Have 5 bytes into buffer. Adding 109 bytes.\n") ;;; (10 "RB: Requested 114 bytes\n") ;;; (5 "REC[0x1bcef00]: Decrypted Packet[1] Application Data(23) with length: 93\n") --------->8--------->8--------->8--------->8--------->8--------->8--------->8--------->8--------- Can someone help? Thanks! From yanfiz at gmail.com Thu May 4 19:45:01 2017 From: yanfiz at gmail.com (Yan Fiz) Date: Thu, 4 May 2017 20:45:01 +0300 Subject: [gnutls-help] Email Protection Key Message-ID: I get "Warning: skipping unknown option 'email_protection_key'" error while use 'email_protection_key' purpose that in mentioned http://gnutls.org/manual/html_node/certtool-Invocation.html. certtool 3.5.11 Example ; $ cat authority.cfg cn=Authority ca path_len=0 cert_signing_key crl_signing_key expiration_days=365 $ cat user.cfg cn=User signing_key non_repudiation encryption_key email_protection_key expiration_days=365 $ certtool --generate-privkey --rsa --bits 2048 --outfile authority.p8 $ certtool --generate-privkey --rsa --bits 2048 --outfile user.p8 $ certtool --generate-self-signed --hash sha512 --load-privkey authority.p8 --outfile authority.crt --template authority.cfg $ certtool --generate-request --hash sha512 --load-privkey user.p8 --outfile user.p10 --template user.cfg Warning: skipping unknown option 'email_protection_key' -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Fri May 5 14:25:17 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 5 May 2017 14:25:17 +0200 Subject: [gnutls-help] Email Protection Key In-Reply-To: References: Message-ID: It seems you have found a bug. That option although documented was not implemented. You can work around that by using: key_purpose_oid = 1.3.6.1.5.5.7.3.4 regards, Nikos On Thu, May 4, 2017 at 7:45 PM, Yan Fiz wrote: > I get "Warning: skipping unknown option 'email_protection_key'" error while > use 'email_protection_key' purpose that in mentioned > http://gnutls.org/manual/html_node/certtool-Invocation.html. > > certtool 3.5.11 > > Example ; > > $ cat authority.cfg > cn=Authority > ca > path_len=0 > cert_signing_key > crl_signing_key > expiration_days=365 > > $ cat user.cfg > cn=User > signing_key > non_repudiation > encryption_key > email_protection_key > expiration_days=365 > > $ certtool --generate-privkey --rsa --bits 2048 --outfile authority.p8 > $ certtool --generate-privkey --rsa --bits 2048 --outfile user.p8 > $ certtool --generate-self-signed --hash sha512 --load-privkey authority.p8 > --outfile authority.crt --template authority.cfg > $ certtool --generate-request --hash sha512 --load-privkey user.p8 --outfile > user.p10 --template user.cfg > Warning: skipping unknown option 'email_protection_key' > > _______________________________________________ > Gnutls-help mailing list > Gnutls-help at lists.gnutls.org > http://lists.gnupg.org/mailman/listinfo/gnutls-help From n.mavrogiannopoulos at gmail.com Tue May 9 14:48:08 2017 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Tue, 9 May 2017 14:48:08 +0200 Subject: [gnutls-help] DER decoding errors due to time format Message-ID: Hi, gnutls 3.5.x is more strict in certificate decoding and performs various checks in the Time fields to ensure they are properly DER formatted. However, it is seems that this caused regressions with certain certificates generated by ovirt as seen in [0]. I am not sure which software was used to generate the problematic ones, however, it is most likely openssl, or some other open source software. Are you aware of other or similar decoding issues which were a result of 3.5.x being more strict in DER rules? The options we have are: 1. Ignore the error and insist on DER correctness in input certificates. 2. Allow incorrect formatted time fields in certificates unconditionally, e.g., with a special libtasn1 flag: https://gitlab.com/gnutls/libtasn1/commit/16bad0c72dcdfbe5512cdd6b46b251ab7484e5dc any other option I've missed? While I favor the first for its simplicity, reality has shown over the years we must yield towards the 'work' part. regards, Nikos [0]. https://gitlab.com/gnutls/gnutls/issues/196 From n.mavrogiannopoulos at gmail.com Tue May 9 20:26:55 2017 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Tue, 09 May 2017 20:26:55 +0200 Subject: [gnutls-help] [gnutls-devel] DER decoding errors due to time format In-Reply-To: <20170509130433.GI1669@redhat.com> References: <20170509130433.GI1669@redhat.com> Message-ID: <1494354415.2148.1.camel@gmail.com> On Tue, 2017-05-09 at 14:04 +0100, Daniel P. Berrange wrote: > On Tue, May 09, 2017 at 02:48:08PM +0200, Nikos Mavrogiannopoulos > wrote: > > Hi, > > ?gnutls 3.5.x is more strict in certificate decoding and performs > > various checks in the Time fields to ensure they are properly DER > > formatted. However, it is seems that this caused regressions with > > certain certificates generated by ovirt as seen in [0]. I am not > > sure > > which software was used to generate the problematic ones, however, > > it > > is most likely openssl, or some other open source software. Are you > > aware of other or similar decoding issues which were a result of > > 3.5.x > > being more strict in DER rules? > > > > The options we have are: > > ?1. Ignore the error and insist on DER correctness in input > > certificates. > > ?2. Allow incorrect formatted time fields in certificates > > unconditionally, e.g., with a special libtasn1 flag: > > https://gitlab.com/gnutls/libtasn1/commit/16bad0c72dcdfbe5512cdd6b4 > > 6b251ab7484e5dc > > > > any other option I've missed? While I favor the first for its > > simplicity, reality has shown over the years we must yield towards > > the > > 'work' part. > > Have you succeeded in getting any contact with oVirt community to > find > out how they are generating their certs ? That might give some > clarity > on whether it is just a minor bug in their code, vs following common/ > wide practice. It isn't clear if it even affects all oVirt users or > just some subset of them, vs likely to affect large numbers of non- > oVirt users too Seems like a good point. I wouldn't know where to ask. Any suggestions? regards, Nikos From n.mavrogiannopoulos at gmail.com Wed May 10 14:06:42 2017 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Wed, 10 May 2017 14:06:42 +0200 Subject: [gnutls-help] [gnutls-devel] DER decoding errors due to time format In-Reply-To: <20170509184709.idwqqb3nmccrclmb@roeckx.be> References: <20170509184709.idwqqb3nmccrclmb@roeckx.be> Message-ID: On Tue, May 9, 2017 at 8:47 PM, Kurt Roeckx wrote: > On Tue, May 09, 2017 at 02:48:08PM +0200, Nikos Mavrogiannopoulos wrote: >> Hi, >> gnutls 3.5.x is more strict in certificate decoding and performs >> various checks in the Time fields to ensure they are properly DER >> formatted. However, it is seems that this caused regressions with >> certain certificates generated by ovirt as seen in [0]. I am not sure >> which software was used to generate the problematic ones, however, it >> is most likely openssl, or some other open source software. Are you >> aware of other or similar decoding issues which were a result of 3.5.x >> being more strict in DER rules? >> >> The options we have are: >> 1. Ignore the error and insist on DER correctness in input certificates. >> 2. Allow incorrect formatted time fields in certificates >> unconditionally, e.g., with a special libtasn1 flag: >> https://gitlab.com/gnutls/libtasn1/commit/16bad0c72dcdfbe5512cdd6b46b251ab7484e5dc >> >> any other option I've missed? While I favor the first for its >> simplicity, reality has shown over the years we must yield towards the >> 'work' part. > > NSS is strict in what it accepts. We've recently changed openssl to be > more strict too (commit 80770da39ebba0101079477611b7ce2f426653c5, > https://github.com/openssl/openssl/issues/2620), but maybe not > strict enough yet. Thank you, that is really helpful. It seems that Kurt has found out the culprit. There seem to be a user input validation issue in openssl when generating certs: https://gitlab.com/gnutls/gnutls/issues/196#note_29192381 regards, Nikos From n.mavrogiannopoulos at gmail.com Wed May 10 14:07:55 2017 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Wed, 10 May 2017 14:07:55 +0200 Subject: [gnutls-help] [gnutls-devel] DER decoding errors due to time format In-Reply-To: References: <20170509184709.idwqqb3nmccrclmb@roeckx.be> Message-ID: On Wed, May 10, 2017 at 2:06 PM, Nikos Mavrogiannopoulos wrote: > On Tue, May 9, 2017 at 8:47 PM, Kurt Roeckx wrote: >> On Tue, May 09, 2017 at 02:48:08PM +0200, Nikos Mavrogiannopoulos wrote: >>> Hi, >>> gnutls 3.5.x is more strict in certificate decoding and performs >>> various checks in the Time fields to ensure they are properly DER >>> formatted. However, it is seems that this caused regressions with >>> certain certificates generated by ovirt as seen in [0]. I am not sure >>> which software was used to generate the problematic ones, however, it >>> is most likely openssl, or some other open source software. Are you >>> aware of other or similar decoding issues which were a result of 3.5.x >>> being more strict in DER rules? >>> >>> The options we have are: >>> 1. Ignore the error and insist on DER correctness in input certificates. >>> 2. Allow incorrect formatted time fields in certificates >>> unconditionally, e.g., with a special libtasn1 flag: >>> https://gitlab.com/gnutls/libtasn1/commit/16bad0c72dcdfbe5512cdd6b46b251ab7484e5dc >>> >>> any other option I've missed? While I favor the first for its >>> simplicity, reality has shown over the years we must yield towards the >>> 'work' part. >> >> NSS is strict in what it accepts. We've recently changed openssl to be >> more strict too (commit 80770da39ebba0101079477611b7ce2f426653c5, >> https://github.com/openssl/openssl/issues/2620), but maybe not >> strict enough yet. > > Thank you, that is really helpful. It seems that Kurt Sorry, I meant to write Tim here! regards, Nikos From nmav at gnutls.org Thu May 11 07:53:21 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 11 May 2017 07:53:21 +0200 Subject: [gnutls-help] gnutls 3.5.12 Message-ID: <1494482001.29735.1.camel@gnutls.org> Hello,? ?I've just released gnutls 3.5.12. This is a bug fix release on the 3.5.x branch. * Version 3.5.12 (released 2017-05-11) ** libgnutls: enabled TCP Fast open for MacOSX. Patch by Tim Ruehsen. ** libgnutls: gnutls_x509_crt_check_hostname2() no longer matches IP addresses against DNS fields of certificate (CN or DNSname). The previous behavior?was to tolerate some misconfigured servers, but that was non-standard?and skipped any IP constraints present in higher level certificates. ** libgnutls: when converting to IDNA2008, fallback to IDNA2003 (i.e., transitional?encoding) if the domain cannot be converted. That provides maximum compatibility?with browsers like firefox that perform the same conversion. ** libgnutls: fix issue in RSA-PSK client callback which resulted in no username?being sent to the peer. Patch by Nicolas Dufresne. ** libgnutls: fix regression causing stapled extensions in trust modules not?to be considered. ** certtool: introduced the email_protection_key option.??This option was introduced?in documentation for certtool without an implementation of it. It is a shortcut for option 'key_purpose_oid =?1.3.6.1.5.5.7.3.4'. ** certtool: made printing of key ID and key PIN consistent between certificates,?public keys, and private keys. That is the private key printing now uses the?same format as the rest. ** gnutls-cli: introduced the --sni-hostname option. This allows? overriding the hostname advertised to the peer. ** 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 compressed sources: ? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.5/gnutls-3.5.12.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.5/gnutls-3.5.12.tar.xz.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 chengwei.clx at gmail.com Thu May 11 17:26:30 2017 From: chengwei.clx at gmail.com (Wei Cheng) Date: Thu, 11 May 2017 23:26:30 +0800 Subject: [gnutls-help] the problem about "stream usage" in dtls/sctp Message-ID: hi,guys! i have read the rfc6083 which describes the usage of the Datagram Transport Layer Security (DTLS) protocol over the Stream Control Transmission Protocol (SCTP). "stream usage " is as follows: 4.4. Stream Usage All DTLS messages of the ChangeCipherSpec, Alert, or Handshake protocol MUST be transported on stream 0 with unlimited reliability and with the ordered delivery feature. DTLS messages of the ApplicationData protocol SHOULD use multiple streams other than stream 0; they MAY use stream 0 for everything if they do not care about minimizing head of line blocking. i write a push_function .like that: static ssize_t push_func(gnutls_transport_ptr_t p, const void *data, size_t size) { priv_data_st *priv = p; int ret; // i sent msg on stream #0 ret = sctp_sendmsg(priv->fd, data,size ,NULL, 0,0, 0,0, 0,0); if (ret < 0) printf("fail to sent msg \n"); else printf("success to sent msg in push\n"); return ret; } i use gnutls_transpoet_set_push_fnuction to register my push function, so that all message would be sent by my push_function. i want to sent alert,handshake,changesuite on stream #0, while appilcaiton data is sent on others streams. in push_function,all data is already encryped, how i can distinguish which kind of msg it is ? how should i write my push_function? i doubt that i am wrong in this part. i sorry about my poor english. thanks any advices! thanks in advance! -------------- next part -------------- An HTML attachment was scrubbed... URL: From chengwei.clx at gmail.com Fri May 12 10:36:14 2017 From: chengwei.clx at gmail.com (Wei Cheng) Date: Fri, 12 May 2017 16:36:14 +0800 Subject: [gnutls-help] the problem about "stream usage" in dtls/sctp In-Reply-To: References: Message-ID: i have made a mistake here. i read the source code today,i found that the first byte of the msg what be sent in my push function is the msg type. i should have a good look at the source code. thanks! 2017-05-11 23:26 GMT+08:00 Wei Cheng : > hi,guys! > > i have read the rfc6083 which describes the usage of the Datagram > Transport Layer Security (DTLS) protocol over the Stream Control > Transmission Protocol (SCTP). > > "stream usage " is as follows: > 4.4. Stream Usage > All DTLS messages of the ChangeCipherSpec, Alert, or Handshake > protocol MUST be transported on stream 0 with unlimited reliability > and with the ordered delivery feature. > DTLS messages of the ApplicationData protocol SHOULD use multiple > streams other than stream 0; they MAY use stream 0 for everything if > they do not care about minimizing head of line blocking. > > > i write a push_function .like that: > static ssize_t push_func(gnutls_transport_ptr_t p, const void *data, > size_t size) > { > priv_data_st *priv = p; > int ret; > // i sent msg on stream #0 > ret = sctp_sendmsg(priv->fd, data,size ,NULL, 0,0, 0,0, 0,0); > if (ret < 0) > printf("fail to sent msg \n"); > else > printf("success to sent msg in push\n"); > return ret; > } > > i use gnutls_transpoet_set_push_fnuction to register my push function, > so that all message would be sent by my push_function. > > > i want to sent alert,handshake,changesuite on stream #0, while appilcaiton > data is sent on others streams. > in push_function,all data is already encryped, > how i can distinguish which kind of msg it is ? > how should i write my push_function? > i doubt that i am wrong in this part. > > i sorry about my poor english. > thanks any advices! > thanks in advance! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Sun May 14 09:43:21 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 14 May 2017 09:43:21 +0200 Subject: [gnutls-help] the problem about "stream usage" in dtls/sctp In-Reply-To: References: Message-ID: <1494747801.2134.2.camel@gnutls.org> On Thu, 2017-05-11 at 23:26 +0800, Wei Cheng wrote: > hi,guys! > > i have read the rfc6083 which ?describes the usage of the Datagram > Transport Layer Security (DTLS) protocol over the Stream Control > Transmission Protocol (SCTP). > > "stream usage " is as follows: > 4.4.? Stream Usage > ? ?All DTLS messages of the ChangeCipherSpec, Alert, or Handshake > ? ?protocol MUST be transported on stream 0 with unlimited > reliability > ? ?and with the ordered delivery feature. > ? ?DTLS messages of the ApplicationData protocol SHOULD use multiple > ? ?streams other than stream 0; they MAY use stream 0 for everything > if > ? ?they do not care about minimizing head of line blocking. > > > i write a push_function .like that: > static ssize_t push_func(gnutls_transport_ptr_t p, const void *data, > size_t size) > { > ? ? priv_data_st *priv = p; > ? ? int ret; > ? ? // ?i sent msg on stream #0 > ? ? ret = sctp_sendmsg(priv->fd, data,size ,NULL, 0,0, 0,0, 0,0); > ? ? if (ret < 0) > ? ? ? ? ?printf("fail to sent msg \n"); > ? ? ?else > ? ? ? ? ?printf("success to sent msg in push\n"); > ? ? ?return ret; > } > > i use gnutls_transpoet_set_push_fnuction to register my push > function, > so that all message would be sent by my push_function. > i want to sent alert,handshake,changesuite on stream #0, while > appilcaiton data is sent on others streams. > in push_function,all data is already encryped, > how i can distinguish which kind of msg it is ? > how should i write my push_function?? > i doubt that i am wrong in this part. Given that you are in DTLS, the data you receive in the push function are a complete record message. Thus you can check the ContentType field of the record message (first byte) to determine the type. The API however was designed for TCP/UDP and although there are few instructions at [1], I'm not happy with that. We need simpler functions to handle SCTP. If you or anyone else has a good proposal for extending gnutls (new push/pull functions and/or a wrapper for gnutls_transport_set_fastopen) for it I'd say go for it and open a merge request. There was an example for TLS over SCTP several years ago, but we most likely need a much simpler version of it for DTLS. [0]. https://lists.gnu.org/archive/html/gnutls-devel/2008-08/msg00009.html [1]. https://www.gnutls.org/manual/html_node/DTLS-and-SCTP.html regards, Nikos From jgh at wizmail.org Sun May 14 14:05:45 2017 From: jgh at wizmail.org (Jeremy Harris) Date: Sun, 14 May 2017 13:05:45 +0100 Subject: [gnutls-help] [gnutls-devel] the problem about "stream usage" in dtls/sctp In-Reply-To: <1494747801.2134.2.camel@gnutls.org> References: <1494747801.2134.2.camel@gnutls.org> Message-ID: <6e36544c-cb67-ddf1-0d11-8ce6b3d5ed16@wizmail.org> On 14/05/17 08:43, Nikos Mavrogiannopoulos wrote: > The API however was designed for TCP/UDP and although there are few > instructions at [1], I'm not happy with that. We need simpler functions > to handle SCTP. Somewhat related - the equivalent of send( , , , MSG_MORE). I could do it with a push function, but that's just more hassle and I'd only be using it for my application protocol startup sequence anyway. - would there be any benefit in a sendfile() equivalent? I assume not for a userland/cpu driven session encryption engine - but are there any hardware engine implementations? -- Cheers, Jeremy [1] NMF. From nmav at gnutls.org Sun May 14 14:59:46 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 14 May 2017 14:59:46 +0200 Subject: [gnutls-help] [gnutls-devel] the problem about "stream usage" in dtls/sctp In-Reply-To: <6e36544c-cb67-ddf1-0d11-8ce6b3d5ed16@wizmail.org> References: <1494747801.2134.2.camel@gnutls.org> <6e36544c-cb67-ddf1-0d11-8ce6b3d5ed16@wizmail.org> Message-ID: <1494766786.1974.2.camel@gnutls.org> On Sun, 2017-05-14 at 13:05 +0100, Jeremy Harris wrote: > On 14/05/17 08:43, Nikos Mavrogiannopoulos wrote: > > The API however was designed for TCP/UDP and although there are few > > instructions at [1], I'm not happy with that. We need simpler > > functions > > to handle SCTP. > > Somewhat related > > - the equivalent of send( , , , MSG_MORE).??I could do it with a push > ? function, but that's just more hassle and I'd only be using it for > ? my application protocol startup sequence anyway. You can use the gnutls_record_cork() and uncork functions for that. Would that work for you, or did I miss the context? > - would there be any benefit in a sendfile() equivalent???I assume > not > ? for a userland/cpu driven session encryption engine - but are there > ? any hardware engine implementations? There is AF_KTLS [0] which can work with gnutls and can be used to achieve sendfile-like functionality. However I do not know whether something like that would ever reach mainline linux kernel. What functionality/optimization do you have in mind? [0]. https://github.com/ktls/af_ktls regards, Nikos From emailmandar at gmail.com Thu May 18 09:56:30 2017 From: emailmandar at gmail.com (Mandar Joshi) Date: Thu, 18 May 2017 13:26:30 +0530 Subject: [gnutls-help] Application Doesn't detect USB Token when started using a systemd script Message-ID: Hi, I noticed that if I start my application using a systemd script, the application cannot see the USB Token. The token I am using is a Feitian technologies one. Bus 003 Device 010: ID 096e:080a Feitian Technologies, Inc. In the application, I am calling gnutls_pkcs11_add_provider ("/usr/lib64/opensc-pkcs11.so", NULL); Is this expected or am I doing something wrong? The same thing happens when I ssh into the Linux box which has the USB token connected to it. I am using Fedora 25 x86_65 with gnutls 3.5.10. Regards Mandar Joshi From nmav at gnutls.org Thu May 18 16:52:15 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 18 May 2017 16:52:15 +0200 Subject: [gnutls-help] Application Doesn't detect USB Token when started using a systemd script In-Reply-To: References: Message-ID: On Thu, May 18, 2017 at 9:56 AM, Mandar Joshi wrote: > Hi, > I noticed that if I start my application using a systemd script, the > application cannot see the USB Token. The token I am using is a > Feitian technologies one. > Bus 003 Device 010: ID 096e:080a Feitian Technologies, Inc. > > In the application, I am calling > gnutls_pkcs11_add_provider ("/usr/lib64/opensc-pkcs11.so", NULL); > > Is this expected or am I doing something wrong? > > The same thing happens when I ssh into the Linux box which has the USB > token connected to it. > > I am using Fedora 25 x86_65 with gnutls 3.5.10. That has nothing to do with gnutls, it is rather a fedora feature restricting access to smart cards to console users: https://access.redhat.com/blogs/766093/posts/1976313 regards, Nikos From emailmandar at gmail.com Fri May 19 01:04:45 2017 From: emailmandar at gmail.com (Mandar Joshi) Date: Fri, 19 May 2017 04:34:45 +0530 Subject: [gnutls-help] Application Doesn't detect USB Token when started using a systemd script In-Reply-To: References: Message-ID: > > That has nothing to do with gnutls, it is rather a fedora feature > restricting access to smart cards to console users: > https://access.redhat.com/blogs/766093/posts/1976313 Thank you Nikos. You saved me a lot of time. For the immediate future, I don't see any need for me to restrict access to the USB tokens on the embedded system that I will be deploying. Or may be i do but I haven't really thought about it. I'll go through the link you provided to see if I can configure my system to grant access to the application started by the systemd start script. Is there a default that I can set so that everyone will have access to the USB Token connected to the system? Regards Mandar Joshi From emailmandar at gmail.com Fri May 19 01:39:32 2017 From: emailmandar at gmail.com (Mandar Joshi) Date: Fri, 19 May 2017 05:09:32 +0530 Subject: [gnutls-help] Application Doesn't detect USB Token when started using a systemd script In-Reply-To: References: Message-ID: > > I'll go through the link you provided to see if I can configure my > system to grant access to the application started by the systemd start > script. Is there a default that I can set so that everyone will have > access to the USB Token connected to the system? > > Added the rules, I can now start the application with "systemctl start ..." The rules are in a file in /usr/share/polkit-1/rules.d --------------------------------------------------------------------------------------------------- polkit.addRule(function(action, subject) { if (action.id == "org.debian.pcsc-lite.access_pcsc" && subject.user == "mandar") { return polkit.Result.YES; } }); polkit.addRule(function(action, subject) { if (action.id == "org.debian.pcsc-lite.access_card" && action.lookup("reader") == 'FT ePass2003Auto 00 00' && subject.user == "mandar") { return polkit.Result.YES; } }); --------------------------------------------------------------------------------------------------- But when starting on boot, ret = gnutls_pkcs11_obj_list_import_url4 return (...) gives ret < 0 Have to debug this problem. From nicolas at babelouest.org Fri May 19 21:44:11 2017 From: nicolas at babelouest.org (Nicolas Mora) Date: Fri, 19 May 2017 15:44:11 -0400 Subject: [gnutls-help] Verifying signatures encoded with gnutls_hmac_fast Message-ID: <2a1843d3-c458-898f-2523-da35bc254ecc@babelouest.org> Hello, I'm trying to adapt libjwt to work with gnutls instead of openssl: https://github.com/benmcollins/libjwt Basically, it's used to sign/verify json web tokens using the following algorithms: HS256, HS384, HS512, RS256, RS384, RS512, ES256, ES384, ES512 With Gnutls, I'm able to sign/verify HS* signatures, I'm also able to sign RS* signatures, but when it comes to verify those, I can't make it work. To sign tokens with RS*, I use gnutls_hmac_fast, but I couldn't find an equivalent to verify the signatures, so I follow the following algorithm: gnutls_pubkey_import(pubkey, &cert_dat, GNUTLS_X509_FMT_PEM); gnutls_pubkey_verify_data2(pubkey, GNUTLS_SIGN_RSA_SHA256, 0, &data, &sig); with sig as a base64 decoded signature, and cert_dat as the content of a public key file The result is always "-89: Public key signature verification has failed." I also tried with GNUTLS_DIG_SHA256 as verify algorithm, the same one used in gnutls_hmac_fast, but it didn't work as well. I couldn't find how to solve my problem, what did I miss? My SHA verifying code can be found at: https://github.com/babelouest/libjwt/blob/gnutls/libjwt/jwt.c#L654 (very quick and dirty, sorry for the mess) From nicolas at babelouest.org Sun May 21 15:06:17 2017 From: nicolas at babelouest.org (Nicolas Mora) Date: Sun, 21 May 2017 09:06:17 -0400 Subject: [gnutls-help] Verifying signatures encoded with gnutls_hmac_fast In-Reply-To: <2a1843d3-c458-898f-2523-da35bc254ecc@babelouest.org> References: <2a1843d3-c458-898f-2523-da35bc254ecc@babelouest.org> Message-ID: <0c4e26e1-6f48-e2bd-c48c-e724e154b5e9@babelouest.org> > I couldn't find how to solve my problem, what did I miss? > OK, I found my solution, I was struggling with incorrect base64 decoded signatures. To answer my own question, the alg I needed to pass to gnutls_pubkey_verify_data2 is the same as the one used in gnutls_privkey_sign_data: GNUTLS_DIG_SHAxxx /Nicolas From jgh at wizmail.org Sun May 21 23:24:14 2017 From: jgh at wizmail.org (Jeremy Harris) Date: Sun, 21 May 2017 22:24:14 +0100 Subject: [gnutls-help] signing Message-ID: Hi, gnutls_x509_privkey_sign_data() is documented as working with an MD5 or SHA1 disgest method: https://www.gnutls.org/manual/html_node/X509-certificate-API.html#index-gnutls_005fx509_005fprivkey_005fsign_005fdata I've seen code calling it with GNUTLS_DIG_SHA256. a) is this properly supported? b) are others? I'm interested in the methods suggested for future DKIM versions: https://tools.ietf.org/html/draft-srose-dkim-ecc-00 namely SHA512 and possibly SHA-3. -- Thanks, Jeremy From nmav at gnutls.org Mon May 22 09:22:28 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 22 May 2017 09:22:28 +0200 Subject: [gnutls-help] signing In-Reply-To: References: Message-ID: On Sun, May 21, 2017 at 11:24 PM, Jeremy Harris wrote: > Hi, > > gnutls_x509_privkey_sign_data() is documented as working with > an MD5 or SHA1 disgest method: > > https://www.gnutls.org/manual/html_node/X509-certificate-API.html#index-gnutls_005fx509_005fprivkey_005fsign_005fdata > > > I've seen code calling it with GNUTLS_DIG_SHA256. The mention of MD5 or SHA1 as the only option is a leftover from the time these were the only option. Any hash is allowed as option. regards, Nikos From nicolas at babelouest.org Wed May 24 18:27:36 2017 From: nicolas at babelouest.org (Nicolas Mora) Date: Wed, 24 May 2017 12:27:36 -0400 Subject: [gnutls-help] How to encode/decode ECDSA signatures to raw format Message-ID: <7a402d94-1927-5875-7ec0-3296c4ff3553@babelouest.org> Hello, I'm still working on porting libjwt https://github.com/benmcollins/libjwt from openssl to gnutls. The last problem I have is about ECDSA signatures. If I use a GNUTLS_PK_EC private key to sign the data with gnutls_privkey_sign_data, the libjwt unit tests fail. I see in the openssl version of libjwt that after signing the data, that it converts to a raw format of R/S, by decoding the signature: https://github.com/benmcollins/libjwt/blob/master/libjwt/jwt-openssl.c#L264 For the verification procedure, it converts back the signature to ASN1: https://github.com/benmcollins/libjwt/blob/master/libjwt/jwt-openssl.c#L386 Are there equivalent functions to encode/decode ECDSA signatures in GnuTLS? Thanks in advance From nmav at gnutls.org Thu May 25 08:30:43 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 25 May 2017 08:30:43 +0200 Subject: [gnutls-help] How to encode/decode ECDSA signatures to raw format In-Reply-To: <7a402d94-1927-5875-7ec0-3296c4ff3553@babelouest.org> References: <7a402d94-1927-5875-7ec0-3296c4ff3553@babelouest.org> Message-ID: On Wed, May 24, 2017 at 6:27 PM, Nicolas Mora wrote: > Hello, > > I'm still working on porting libjwt https://github.com/benmcollins/libjwt > from openssl to gnutls. > > The last problem I have is about ECDSA signatures. If I use a GNUTLS_PK_EC > private key to sign the data with gnutls_privkey_sign_data, the libjwt unit > tests fail. > > I see in the openssl version of libjwt that after signing the data, that it > converts to a raw format of R/S, by decoding the signature: > https://github.com/benmcollins/libjwt/blob/master/libjwt/jwt-openssl.c#L264 > > For the verification procedure, it converts back the signature to ASN1: > https://github.com/benmcollins/libjwt/blob/master/libjwt/jwt-openssl.c#L386 > > Are there equivalent functions to encode/decode ECDSA signatures in GnuTLS? Unfortunately there isn't any such function. Since 3.5.x there is an exported, but still internal function _gnutls_decode_ber_rs_raw() for that. I created an issue to export them for 3.6.0, but until then you may want to replicate them to use them. regards, Nikos [0]. https://gitlab.com/gnutls/gnutls/issues/205 From emailmandar at gmail.com Thu May 25 16:23:45 2017 From: emailmandar at gmail.com (Mandar Joshi) Date: Thu, 25 May 2017 19:53:45 +0530 Subject: [gnutls-help] GnuTLS on ARMv7 and HardFP In-Reply-To: References: Message-ID: > When using gnutls_cipher_decrypt2 on Odroid C1 and Raspberry Pi > running Gentoo (armv7a-hardfloat-linux-gnueabi), the program > terminates with "Floating Point Exception" I meant Raspberry Pi 2 From emailmandar at gmail.com Thu May 25 16:22:55 2017 From: emailmandar at gmail.com (Mandar Joshi) Date: Thu, 25 May 2017 19:52:55 +0530 Subject: [gnutls-help] GnuTLS on ARMv7 and HardFP Message-ID: Hello, When using gnutls_cipher_decrypt2 on Odroid C1 and Raspberry Pi running Gentoo (armv7a-hardfloat-linux-gnueabi), the program terminates with "Floating Point Exception" Is this expected on ARMv7 or did I mess up some USE flags while compiling the system ? I tried compiling the program with -march=native but that made no difference? What are my options? I am going to try a different stage3 from Gentoo, one without HardFP. Is that the only way? Regards Mandar Joshi From n.mavrogiannopoulos at gmail.com Thu May 25 19:49:58 2017 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Thu, 25 May 2017 19:49:58 +0200 Subject: [gnutls-help] GnuTLS on ARMv7 and HardFP In-Reply-To: References: Message-ID: Hi, Did you compile on these systems? What is the output of make check for nettle and gnutls? On May 25, 2017 16:25, "Mandar Joshi" wrote: > > When using gnutls_cipher_decrypt2 on Odroid C1 and Raspberry Pi > > running Gentoo (armv7a-hardfloat-linux-gnueabi), the program > > terminates with "Floating Point Exception" > > I meant Raspberry Pi 2 > > _______________________________________________ > Gnutls-help mailing list > Gnutls-help at lists.gnutls.org > http://lists.gnupg.org/mailman/listinfo/gnutls-help > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas at babelouest.org Thu May 25 21:01:02 2017 From: nicolas at babelouest.org (Nicolas Mora) Date: Thu, 25 May 2017 15:01:02 -0400 Subject: [gnutls-help] How to encode/decode ECDSA signatures to raw format In-Reply-To: References: <7a402d94-1927-5875-7ec0-3296c4ff3553@babelouest.org> Message-ID: <25157751-618d-797e-a0d3-1ef8d3057a52@babelouest.org> Hello, > > Unfortunately there isn't any such function. Since 3.5.x there is an > exported, but still internal function _gnutls_decode_ber_rs_raw() for > that. I created an issue to export them for 3.6.0, but until then you > may want to replicate them to use them. > Thanks for the answer, There goes another question related to _gnutls_decode_ber_rs_raw(). When I use it with a newly created signature, I got 2 output parameters R and S. Each of them have a size parameter of 48 or 49, whatever the algorithm size used. If I read the RFC 7518: https://tools.ietf.org/html/rfc7518#section-3.4 , it says that for a ECDSA P-256 SHA-256 digital signature, R and S must be 256-bit unsigned integers. I looked at the content of the values R and S set by _gnutls_decode_ber_rs_raw(), it doesn't look like they have '0' padding so I assume every bit is relevant. So there must be some problems with my usage. With these 256 bits parameters, I must build 2 32 bytes long array that are the representation of the parameters R and S, then concatenate them in a 64 byte sequence to have my signature. My current usage is the following: gnutls_privkey_sign_data(privkey, alg, 0, &body_dat, &sig_dat) _gnutls_decode_ber_rs_raw(&sig_dat, &r, &s) Is it the right way to use this function or should I use it differently? If this is the right way, how to convert my R and S parameters into 32 bytes big endian array? Thanks in advance /Nicolas From nmav at gnutls.org Fri May 26 09:05:24 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 26 May 2017 09:05:24 +0200 Subject: [gnutls-help] How to encode/decode ECDSA signatures to raw format In-Reply-To: <25157751-618d-797e-a0d3-1ef8d3057a52@babelouest.org> References: <7a402d94-1927-5875-7ec0-3296c4ff3553@babelouest.org> <25157751-618d-797e-a0d3-1ef8d3057a52@babelouest.org> Message-ID: On Thu, May 25, 2017 at 9:01 PM, Nicolas Mora wrote: > Hello, > >> >> Unfortunately there isn't any such function. Since 3.5.x there is an >> exported, but still internal function _gnutls_decode_ber_rs_raw() for >> that. I created an issue to export them for 3.6.0, but until then you >> may want to replicate them to use them. >> > > Thanks for the answer, > > There goes another question related to _gnutls_decode_ber_rs_raw(). When I > use it with a newly created signature, I got 2 output parameters R and S. > Each of them have a size parameter of 48 or 49, whatever the algorithm size > used. The integers returned by that function are (left) zero-padded to avoid having them interpreted as negative integers. About the size being 48 or 49 irrespective of key, it seems something is wrong there. Most likely you are using the SECP384 curve. If not could you send a small reproducer? regards, Nikos From emailmandar at gmail.com Fri May 26 17:54:51 2017 From: emailmandar at gmail.com (Mandar Joshi) Date: Fri, 26 May 2017 21:24:51 +0530 Subject: [gnutls-help] GnuTLS on ARMv7 and HardFP In-Reply-To: References: Message-ID: Hello Nikos, > Did you compile on these systems? Yes. Using portage on Gentoo, with help from distcc on my main box. > What is the output of make check for nettle and gnutls? Compiled manually to check this. The make check test passed successfully for both nettle and gnutls. I was using GNUTLS_CIPHER_AES_256_CBC After changing that to GNUTLS_CIPHER_AES_256_GCM, I don't get the "Floating point exception". I've attached 2 files. test_gnutls.c uses GNUTLS_CIPHER_AES_256_GCM and works on both Fedora 25 x86_64 and Gentoo ARMv7 HardFP test_gnutls2.c uses GNUTLS_CIPHER_AES_256_CBC and works only on Fedora 25 x86_64 Can you please check what I'm doing wrong? Thanks Mandar Joshi -------------- next part -------------- A non-text attachment was scrubbed... Name: test_gnutls2.c Type: text/x-csrc Size: 1383 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test_gnutls.c Type: text/x-csrc Size: 1381 bytes Desc: not available URL: From nicolas at babelouest.org Fri May 26 17:55:09 2017 From: nicolas at babelouest.org (Nicolas Mora) Date: Fri, 26 May 2017 11:55:09 -0400 Subject: [gnutls-help] How to encode/decode ECDSA signatures to raw format In-Reply-To: References: <7a402d94-1927-5875-7ec0-3296c4ff3553@babelouest.org> <25157751-618d-797e-a0d3-1ef8d3057a52@babelouest.org> Message-ID: <446dc072-9504-c9a5-7e0b-20d88d145a73@babelouest.org> Le 2017-05-26 ? 03:05, Nikos Mavrogiannopoulos a ?crit : > The integers returned by that function are (left) zero-padded to avoid > having them interpreted as negative integers. About the size being 48 > or 49 irrespective of key, it seems something is wrong there. Most > likely you are using the SECP384 curve. If not could you send a small > reproducer? > Oooooohhhh I think you're right, I was using bad certificates for my tests... For some reason, sometimes I have r.size that is less than the expected size. But I assume this is not a bug and I add 0 padding to complete the signature. Thanks a lot for your help, very much appreciated! /Nicolas Mora From n.mavrogiannopoulos at gmail.com Sun May 28 13:13:46 2017 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Sun, 28 May 2017 13:13:46 +0200 Subject: [gnutls-help] GnuTLS on ARMv7 and HardFP In-Reply-To: References: Message-ID: Could you catch this fpe using gdb and send if along with the contents of /proc/cpuinfo? On May 26, 2017 17:55, "Mandar Joshi" wrote: > Hello Nikos, > > > Did you compile on these systems? > Yes. Using portage on Gentoo, with help from distcc on my main box. > > > What is the output of make check for nettle and gnutls? > Compiled manually to check this. The make check test passed > successfully for both nettle and gnutls. > > > I was using GNUTLS_CIPHER_AES_256_CBC > After changing that to GNUTLS_CIPHER_AES_256_GCM, I don't get the > "Floating point exception". > > I've attached 2 files. > test_gnutls.c uses GNUTLS_CIPHER_AES_256_GCM and works on both Fedora > 25 x86_64 and Gentoo ARMv7 HardFP > test_gnutls2.c uses GNUTLS_CIPHER_AES_256_CBC and works only on Fedora 25 > x86_64 > > > Can you please check what I'm doing wrong? > > Thanks > Mandar Joshi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.mavrogiannopoulos at gmail.com Mon May 29 09:53:26 2017 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Mon, 29 May 2017 09:53:26 +0200 Subject: [gnutls-help] [gnutls-devel] DER decoding errors due to time format In-Reply-To: <20170511164631.d7v7i7nmjg5yt5cc@roeckx.be> References: <20170509184709.idwqqb3nmccrclmb@roeckx.be> <20170511164631.d7v7i7nmjg5yt5cc@roeckx.be> Message-ID: On Thu, May 11, 2017 at 6:46 PM, Kurt Roeckx wrote: > On Wed, May 10, 2017 at 02:07:55PM +0200, Nikos Mavrogiannopoulos wrote: >> On Wed, May 10, 2017 at 2:06 PM, Nikos Mavrogiannopoulos >> wrote: >> > On Tue, May 9, 2017 at 8:47 PM, Kurt Roeckx wrote: >> >> On Tue, May 09, 2017 at 02:48:08PM +0200, Nikos Mavrogiannopoulos wrote: >> >>> Hi, >> >>> gnutls 3.5.x is more strict in certificate decoding and performs >> >>> various checks in the Time fields to ensure they are properly DER >> >>> formatted. However, it is seems that this caused regressions with >> >>> certain certificates generated by ovirt as seen in [0]. I am not sure >> >>> which software was used to generate the problematic ones, however, it >> >>> is most likely openssl, or some other open source software. Are you >> >>> aware of other or similar decoding issues which were a result of 3.5.x >> >>> being more strict in DER rules? >> >>> >> >>> The options we have are: >> >>> 1. Ignore the error and insist on DER correctness in input certificates. >> >>> 2. Allow incorrect formatted time fields in certificates >> >>> unconditionally, e.g., with a special libtasn1 flag: >> >>> https://gitlab.com/gnutls/libtasn1/commit/16bad0c72dcdfbe5512cdd6b46b251ab7484e5dc >> >>> >> >>> any other option I've missed? While I favor the first for its >> >>> simplicity, reality has shown over the years we must yield towards the >> >>> 'work' part. >> >> >> >> NSS is strict in what it accepts. We've recently changed openssl to be >> >> more strict too (commit 80770da39ebba0101079477611b7ce2f426653c5, >> >> https://github.com/openssl/openssl/issues/2620), but maybe not >> >> strict enough yet. >> > >> > Thank you, that is really helpful. It seems that Kurt >> >> Sorry, I meant to write Tim here! > > And today someone filed this in Debian: > https://bugs.debian.org/862335 I have a patch set which will tolerate incorrectly formatted dates to work around these issues in openssl: https://gitlab.com/gnutls/gnutls/merge_requests/400 I am still not sure that tolerating invalid formatted data is a good thing, however, in case of infrastructure already deployed based on openssl tools, there is not much an administrator/user can do. What I'm thinking to do is set a cut-off date after which the original strict behavior will be re-instated, though I cannot see how would that help eliminating that issue. regards, Nikos From tim.ruehsen at gmx.de Wed May 31 09:37:14 2017 From: tim.ruehsen at gmx.de (=?UTF-8?Q?Tim_R=c3=bchsen?=) Date: Wed, 31 May 2017 09:37:14 +0200 Subject: [gnutls-help] [gnutls-devel] DER decoding errors due to time format In-Reply-To: References: <20170509184709.idwqqb3nmccrclmb@roeckx.be> <20170511164631.d7v7i7nmjg5yt5cc@roeckx.be> Message-ID: On 05/29/2017 09:53 AM, Nikos Mavrogiannopoulos wrote: > On Thu, May 11, 2017 at 6:46 PM, Kurt Roeckx wrote: >> On Wed, May 10, 2017 at 02:07:55PM +0200, Nikos Mavrogiannopoulos wrote: >>> On Wed, May 10, 2017 at 2:06 PM, Nikos Mavrogiannopoulos >>> wrote: >>>> On Tue, May 9, 2017 at 8:47 PM, Kurt Roeckx wrote: >>>>> On Tue, May 09, 2017 at 02:48:08PM +0200, Nikos Mavrogiannopoulos wrote: >>>>>> Hi, >>>>>> gnutls 3.5.x is more strict in certificate decoding and performs >>>>>> various checks in the Time fields to ensure they are properly DER >>>>>> formatted. However, it is seems that this caused regressions with >>>>>> certain certificates generated by ovirt as seen in [0]. I am not sure >>>>>> which software was used to generate the problematic ones, however, it >>>>>> is most likely openssl, or some other open source software. Are you >>>>>> aware of other or similar decoding issues which were a result of 3.5.x >>>>>> being more strict in DER rules? >>>>>> >>>>>> The options we have are: >>>>>> 1. Ignore the error and insist on DER correctness in input certificates. >>>>>> 2. Allow incorrect formatted time fields in certificates >>>>>> unconditionally, e.g., with a special libtasn1 flag: >>>>>> https://gitlab.com/gnutls/libtasn1/commit/16bad0c72dcdfbe5512cdd6b46b251ab7484e5dc >>>>>> >>>>>> any other option I've missed? While I favor the first for its >>>>>> simplicity, reality has shown over the years we must yield towards the >>>>>> 'work' part. >>>>> >>>>> NSS is strict in what it accepts. We've recently changed openssl to be >>>>> more strict too (commit 80770da39ebba0101079477611b7ce2f426653c5, >>>>> https://github.com/openssl/openssl/issues/2620), but maybe not >>>>> strict enough yet. >>>> >>>> Thank you, that is really helpful. It seems that Kurt >>> >>> Sorry, I meant to write Tim here! >> >> And today someone filed this in Debian: >> https://bugs.debian.org/862335 > > I have a patch set which will tolerate incorrectly formatted dates to > work around these issues in openssl: > https://gitlab.com/gnutls/gnutls/merge_requests/400 > > I am still not sure that tolerating invalid formatted data is a good > thing, however, in case of infrastructure already deployed based on > openssl tools, there is not much an administrator/user can do. What > I'm thinking to do is set a cut-off date after which the original > strict behavior will be re-instated, though I cannot see how would > that help eliminating that issue. OpenSSL just 'allows' an invalid format, it's not really buggy (at least not 1.1.1-dev, maybe older versions !?). The question is how many public deployments are really affected, e.g. how many of the top 1M sites use certs with invalid dates ? Maybe there are just a few broken scripts out there, generating invalid certs. These should be fixed first to allow for a smooth update to a 'fixed' version of OpenSSL. With Best Regards, Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: