1. 03 10月, 2016 1 次提交
  2. 23 9月, 2016 1 次提交
  3. 13 9月, 2016 1 次提交
  4. 22 8月, 2016 1 次提交
    • M
      Fix DTLS buffered message DoS attack · f5c7f5df
      Matt Caswell 提交于
      DTLS can handle out of order record delivery. Additionally since
      handshake messages can be bigger than will fit into a single packet, the
      messages can be fragmented across multiple records (as with normal TLS).
      That means that the messages can arrive mixed up, and we have to
      reassemble them. We keep a queue of buffered messages that are "from the
      future", i.e. messages we're not ready to deal with yet but have arrived
      early. The messages held there may not be full yet - they could be one
      or more fragments that are still in the process of being reassembled.
      
      The code assumes that we will eventually complete the reassembly and
      when that occurs the complete message is removed from the queue at the
      point that we need to use it.
      
      However, DTLS is also tolerant of packet loss. To get around that DTLS
      messages can be retransmitted. If we receive a full (non-fragmented)
      message from the peer after previously having received a fragment of
      that message, then we ignore the message in the queue and just use the
      non-fragmented version. At that point the queued message will never get
      removed.
      
      Additionally the peer could send "future" messages that we never get to
      in order to complete the handshake. Each message has a sequence number
      (starting from 0). We will accept a message fragment for the current
      message sequence number, or for any sequence up to 10 into the future.
      However if the Finished message has a sequence number of 2, anything
      greater than that in the queue is just left there.
      
      So, in those two ways we can end up with "orphaned" data in the queue
      that will never get removed - except when the connection is closed. At
      that point all the queues are flushed.
      
      An attacker could seek to exploit this by filling up the queues with
      lots of large messages that are never going to be used in order to
      attempt a DoS by memory exhaustion.
      
      I will assume that we are only concerned with servers here. It does not
      seem reasonable to be concerned about a memory exhaustion attack on a
      client. They are unlikely to process enough connections for this to be
      an issue.
      
      A "long" handshake with many messages might be 5 messages long (in the
      incoming direction), e.g. ClientHello, Certificate, ClientKeyExchange,
      CertificateVerify, Finished. So this would be message sequence numbers 0
      to 4. Additionally we can buffer up to 10 messages in the future.
      Therefore the maximum number of messages that an attacker could send
      that could get orphaned would typically be 15.
      
      The maximum size that a DTLS message is allowed to be is defined by
      max_cert_list, which by default is 100k. Therefore the maximum amount of
      "orphaned" memory per connection is 1500k.
      
      Message sequence numbers get reset after the Finished message, so
      renegotiation will not extend the maximum number of messages that can be
      orphaned per connection.
      
      As noted above, the queues do get cleared when the connection is closed.
      Therefore in order to mount an effective attack, an attacker would have
      to open many simultaneous connections.
      
      Issue reported by Quan Luo.
      
      CVE-2016-2179
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      f5c7f5df
  5. 18 8月, 2016 1 次提交
  6. 05 8月, 2016 1 次提交
    • D
      Make DTLS1_BAD_VER work with DTLS_client_method() · 032924c4
      David Woodhouse 提交于
      DTLSv1_client_method() is deprecated, but it was the only way to obtain
      DTLS1_BAD_VER support. The SSL_OP_CISCO_ANYCONNECT hack doesn't work with
      DTLS_client_method(), and it's relatively non-trivial to make it work without
      expanding the hack into lots of places.
      
      So deprecate SSL_OP_CISCO_ANYCONNECT with DTLSv1_client_method(), and make
      it work with SSL_CTX_set_{min,max}_proto_version(DTLS1_BAD_VER) instead.
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      Reviewed-by: NMatt Caswell <matt@openssl.org>
      032924c4
  7. 20 7月, 2016 1 次提交
  8. 29 6月, 2016 1 次提交
  9. 22 6月, 2016 1 次提交
  10. 18 5月, 2016 1 次提交
  11. 05 5月, 2016 1 次提交
  12. 29 4月, 2016 1 次提交
  13. 05 4月, 2016 2 次提交
  14. 22 3月, 2016 1 次提交
  15. 18 3月, 2016 1 次提交
  16. 10 3月, 2016 1 次提交
  17. 23 2月, 2016 1 次提交
  18. 12 2月, 2016 1 次提交
  19. 06 2月, 2016 3 次提交
  20. 04 2月, 2016 1 次提交
  21. 01 2月, 2016 1 次提交
  22. 27 1月, 2016 1 次提交
    • R
      Remove /* foo.c */ comments · 34980760
      Rich Salz 提交于
      This was done by the following
              find . -name '*.[ch]' | /tmp/pl
      where /tmp/pl is the following three-line script:
              print unless $. == 1 && m@/\* .*\.[ch] \*/@;
              close ARGV if eof; # Close file to reset $.
      
      And then some hand-editing of other files.
      Reviewed-by: NViktor Dukhovni <viktor@openssl.org>
      34980760
  23. 25 1月, 2016 1 次提交
    • R
      Move pqueue into ssl · cf2cede4
      Rich Salz 提交于
      This is an internal facility, never documented, not for
      public consumption.  Move it into ssl (where it's only used
      for DTLS).
      
      I also made the typedef's for pqueue and pitem follow our style: they
      name structures, not pointers.
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      cf2cede4
  24. 11 1月, 2016 1 次提交
  25. 02 1月, 2016 2 次提交
    • V
      Protocol version selection and negotiation rewrite · 4fa52141
      Viktor Dukhovni 提交于
      The protocol selection code is now consolidated in a few consecutive
      short functions in a single file and is table driven.  Protocol-specific
      constraints that influence negotiation are moved into the flags
      field of the method structure.  The same protocol version constraints
      are now applied in all code paths.  It is now much easier to add
      new protocol versions without reworking the protocol selection
      logic.
      
      In the presence of "holes" in the list of enabled client protocols
      we no longer select client protocols below the hole based on a
      subset of the constraints and then fail shortly after when it is
      found that these don't meet the remaining constraints (suiteb, FIPS,
      security level, ...).  Ideally, with the new min/max controls users
      will be less likely to create "holes" in the first place.
      Reviewed-by: NKurt Roeckx <kurt@openssl.org>
      4fa52141
    • K
      7946ab33
  26. 26 11月, 2015 1 次提交
  27. 10 11月, 2015 1 次提交
  28. 02 11月, 2015 1 次提交
  29. 30 10月, 2015 6 次提交
  30. 09 10月, 2015 1 次提交
  31. 23 9月, 2015 1 次提交