1. 02 2月, 2020 2 次提交
  2. 31 1月, 2020 9 次提交
  3. 30 1月, 2020 4 次提交
  4. 29 1月, 2020 7 次提交
  5. 28 1月, 2020 3 次提交
  6. 27 1月, 2020 2 次提交
  7. 26 1月, 2020 1 次提交
  8. 25 1月, 2020 6 次提交
    • K
      Check that the default signature type is allowed · b0031e5d
      Kurt Roeckx 提交于
      TLS < 1.2 has fixed signature algorithms: MD5+SHA1 for RSA and SHA1 for the
      others. TLS 1.2 sends a list of supported ciphers, but allows not sending
      it in which case SHA1 is used. TLS 1.3 makes sending the list mandatory.
      
      When we didn't receive a list from the client, we always used the
      defaults without checking that they are allowed by the configuration.
      Reviewed-by: NPaul Dale <paul.dale@oracle.com>
      GH: #10784
      b0031e5d
    • K
      Replace apps/server.pem with certificate with a sha256 signature. · 5fd72d96
      Kurt Roeckx 提交于
      It replaces apps/server.pem that used a sha1 signature with a copy of
      test/certs/servercert.pem that is uses sha256.
      
      This caused the dtlstest to start failing. It's testing connection
      sbetween a dtls client and server. In particular it was checking that if
      we drop a record that the handshake recovers and still completes
      successfully. The test iterates a number of times. The first time
      through it drops the first record. The second time it drops the second
      one, and so on. In order to do this it has a hard-coded value for the
      expected number of records it should see in a handshake. That's ok
      because we completely control both sides of the handshake and know what
      records we expect to see. Small changes in message size would be
      tolerated because that is unlikely to have an impact on the number of
      records. Larger changes in message size however could increase or
      decrease the number of records and hence cause the test to fail.
      
      This particular test uses a mem bio which doesn't have all the CTRLs
      that the dgram BIO has. When we are using a dgram BIO we query that BIO
      to determine the MTU size. The smaller the MTU the more fragmented
      handshakes become. Since the mem BIO doesn't report an MTU we use a
      rather small default value and get quite a lot of records in our
      handshake. This has the tendency to increase the likelihood of the
      number of records changing in the test if the message size changes.
      
      It so happens that the new server certificate is smaller than the old
      one. AFAICT this is probably because the DNs for the Subject and Issuer
      are significantly shorter than previously. The result is that the number
      of records used to transmit the Certificate message is one less than it
      was before. This actually has a knock on impact for subsequent messages
      and how we fragment them resulting in one less ServerKeyExchange record
      too (the actual size of the ServerKeyExchange message hasn't changed,
      but where in that message it gets fragmented has). In total the number
      of records used in the handshake has decreased by 2 with the new
      server.pem file.
      Reviewed-by: NPaul Dale <paul.dale@oracle.com>
      GH: #10784
      5fd72d96
    • R
      EVP: Adapt EVP_PKEY Seal and Open for provider keys · 9420b403
      Richard Levitte 提交于
      This affects the following function, which can now deal with provider
      side keys:
      
      - EVP_SealInit()
      - EVP_OpenInit()
      Reviewed-by: NShane Lontis <shane.lontis@oracle.com>
      (Merged from https://github.com/openssl/openssl/pull/10808)
      9420b403
    • B
      openssl-config: add example libssl system-defaults · 3472082b
      Benjamin Kaduk 提交于
      Provide a "simple" example for affecting the systemwide default behavior
      of libssl.  The large number of mandatory nested sections makes this
      less simple than the main description might suggest.
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/10937)
      3472082b
    • P
      Deprecate the low level DES functions. · c6fec81b
      Pauli 提交于
      Use of the low level DES functions has been informally discouraged for a
      long time. We now formally deprecate them.
      
      Applications should instead use the EVP APIs, e.g. EVP_EncryptInit_ex,
      EVP_EncryptUpdate, EVP_EncryptFinal_ex, and the equivalently named decrypt
      functions.
      Reviewed-by: NTomas Mraz <tmraz@fedoraproject.org>
      (Merged from https://github.com/openssl/openssl/pull/10858)
      c6fec81b
    • P
  9. 24 1月, 2020 6 次提交