TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks Справочная информация по SSL сертификатам Украина ☎ +380672576220 

☎ +380443834054
☎ +380672576220
Ukrainian Symantec Partner
Ukrainian DigiCert Partner
Контакты
Официальные документы RFC для сертификатов
технические требования, спецификации и стандарты

Переход на сайт по продаже сертификатов SSL и подписи кода документов почты CSR
pKey
Установка
SSL
Цепочка
SSL
Проверка
SSL
Seal
SSL
Экспорт-Импорт
Конвертер
Code Sign
сертификаты
Email Smime
сертификаты
PDF и Word
сертификаты
База
знаний

Обзор требований стандарта сертификатов x.509Стандарт x.509
Документы RFC
rfc765 протокол ФТП
rfc854 протокол ТЕЛНЕТ
rfc1035 доменные имена
rfc1321 алгоритм MD5
rfc1945 протокол HTTP/1.0
rfc2119 ключевые слова
rfc2246 TLS протокол v.1.0
rfc2246* TLS протокол v.1 new
rfc2437 спецификация RSA 2.0
rfc2459 x.509 профиль CRL
rfc2511 x.509 форма запроса
rfc2527 x.509 принципы
rfc2549 стандарт IP
rfc2560 x.509 - OCSP
rfc2585 x.509 FTP HTTP
rfc2616 протокол HTTP / 1.1
rfc2986 Спецификация CSR
rfc3029 x.509 протокол данных
rfc3161 x.509 метка времени
rfc3279 x.509 профиль CRL
rfc3280 x.509 профиль CRL*
rfc3281 атрибуты сертификата
rfc3443 процесс TTL
rfc3447 спецификация RSA 2.1
rfc3546 расширения TLS
rfc3597 обработка DNS RR
rfc3647 x.509 полис*
rfc3709 x.509 логотипы
rfc3739 x.509 профиль*
rfc3779 x.509 IP и AS
rfc4043 x.509 идентификатор
rfc4051 XML URI
rfc4055 x.509 RSA
rfc4059 x.509 гарантии
rfc4158 x.509 цепь доверия
rfc4210 x.509 протокол CMP
rfc4211 x.509 запрос*
rfc4212 x.509 CRMF PKIX
rfc4262 x.509 s/mime
rfc4325 x.509 профиль CRL**
rfc4346 TLS протокол v.1.1
rfc4366 TLS протокол v.1.1*
rfc4523 x.509 протокол LDAP
rfc5019 SMTP для особых сред
rfc5070 Обмена данными
rfc5246 TLS протокол 1.2
rfc5280 x.509 профиль CRL
rfc5480 ECC криптография
rfc5698 DSSC структура
rfc5741 RFC информация
rfc5750 s/mime v.3.2
rfc6066 TLS протокол
rfc6101 SSL протокол v.3.0
rfc6394 DNS DANE
rfc6454 Концепция Web Origin
rfc6455 WebSocket протокол
rfc6520 DTLS расширения TLS
rfc6546 RID HTTP/TLS
rfc6698 TLSA и DNS DANE
rfc6797 HSTS протокол
rfc6844 CAA DNS записи
rfc6960 OCSP статус
rfc6962 Прозрачность
rfc8446 TLS 1.3

We are an Authorized Reseller for DigiCert™ SSL a WebTrust Certified
SSL Certificate Authority.

Значение пакета TLS Fallback Signaling Cipher Suite (SCSV) для предотвращения отказа протокола. Атаки draft-bmoeller-tls-downgrade-scsv-01


Абстрактные

    В этом документе определяется значение набора сигнатурного шифрования (SCSV), которое
    предотвращает атаки с понижением уровня протокола на безопасность транспортного уровня
    (TLS).

Статус этой заметки

    Настоящий Интернет-проект представляется в полном соответствии с
    положениям BCP 78 и BCP 79.

    Интернет-проекты - это рабочие документы Internet Engineering
    Целевой группы (IETF). Обратите внимание, что другие группы также могут распространять
    рабочих документов в виде интернет-проектов. Список текущих интернет-
    Черновики находятся по адресу http://datatracker.ietf.org/drafts/current/.

    Интернет-проекты - это проекты документов, действительные в течение максимум шести месяцев
    и могут быть обновлены, заменены или устарели другими документами на любом
    время. Нецелесообразно использовать Internet-Drafts в качестве ссылки
    материала или ссылаться на них, кроме как «работа в процессе».

=====================================

Network Working Group                                         B. Moeller
Internet-Draft                                                A. Langley
Updates: 2246,4346,5246                                           Google
(if approved)                                          November 28, 2013
Intended status: Standards Track
Expires: June 1, 2014


TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol
                           Downgrade Attacks
                  draft-bmoeller-tls-downgrade-scsv-01

Abstract

   This document defines a Signaling Cipher Suite Value (SCSV) that
   prevents protocol downgrade attacks on the Transport Layer Security
   (TLS) protocol.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on June 1, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as



Moeller & Langley         Expires June 1, 2014                  [Page 1]

Internet-Draft              TLS Fallback SCSV              November 2013


   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Protocol values  . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Server behavior  . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Client behavior  . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     6.1.  Normative References . . . . . . . . . . . . . . . . . . .  8
     6.2.  Informal References  . . . . . . . . . . . . . . . . . . .  8
   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10




































Moeller & Langley         Expires June 1, 2014                  [Page 2]

Internet-Draft              TLS Fallback SCSV              November 2013


1.  Introduction

   To work around interoperability problems with legacy servers, many
   TLS client implementations do not rely on the TLS protocol version
   negotiation mechanism alone, but will intentionally reconnect using a
   downgraded protocol if initial handshake attempts fail.  Such clients
   may fall back to connections in which they announce a version as low
   as TLS 1.0 (or even its predecessor, SSL 3.0) as the highest
   supported version.

   While such protocol downgrades can be a useful last resort for
   connections to actual legacy servers, there's a risk that active
   attackers could exploit the downgrade strategy to weaken the
   cryptographic security of connections.  Also, handshake errors due to
   network glitches could similary be misinterpreted as interaction with
   a legacy server and result in a protocol downgrade.

   All unnecessary protocol downgrades are undesirable (e.g., from TLS
   1.2 to TLS 1.1 if both the client and the server actually do support
   TLS 1.2); they can be particularly critical if they mean losing the
   TLS extension feature (when downgrading to SSL 3.0).  This document
   defines a Signaling Cipher Suite Value (SCSV) that can be employed to
   prevent unintended protocol downgrades between clients and servers
   that comply to this document, by having the client indicate that the
   current connection attempt is merely a fallback.

   This specification applies to implementations of TLS 1.0 [RFC2246],
   TLS 1.1 [RFC4346], and TLS 1.2 [RFC5246].  (It is particularly
   relevant if such implementations also include support for predecessor
   protocol SSL 3.0 [RFC6101].)  It can be applied similarly to later
   protocol versions.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].
















Moeller & Langley         Expires June 1, 2014                  [Page 3]

Internet-Draft              TLS Fallback SCSV              November 2013


2.  Protocol values

   [[ NOTE IN DRAFT: The following registry allocations require
   Standards Action, i.e. will only be official with the IESG's
   Standards Track RFC approval. ]]

   This document allocates a new cipher suite value in the TLS Cipher
   Suite Registry [RFC5246]:

        TLS_FALLBACK_SCSV          {0x56, 0x00}


   This is a signaling cipher suite value, i.e., it does not actually
   correspond to a suite of cryptosystems, and it can never be selected
   by the server in the handshake; rather, its presence in the client
   hello message serves as a backwards-compatible signal from the client
   to the server.

   This document also allocates a new alert value in the TLS Alert
   Registry [RFC5246]:

        enum {
          /* ... */
          inappropriate_fallback(86),
          /* ... */
          (255)
        } AlertDescription;


   This alert is only generated by servers, as described in Section 3.
   It is always fatal.




















Moeller & Langley         Expires June 1, 2014                  [Page 4]

Internet-Draft              TLS Fallback SCSV              November 2013


3.  Server behavior

   This section specifies server behavior when receiving the
   TLS_FALLBACK_SCSV cipher suite from a client in
   ClientHello.cipher_suites.

   o  If TLS_FALLBACK_SCSV appears in ClientHello.cipher_suites and the
      highest protocol version supported by the server is higher than
      the version indicated in ClientHello.client_version, the server
      MUST respond with a inappropriate_fallback alert.

   Otherwise (either TLS_FALLBACK_SCSV does not appear, or it appears
   and the client's protocol version is at least the highest protocol
   version supported by the server), the server proceeds with the
   handshake as usual.




































Moeller & Langley         Expires June 1, 2014                  [Page 5]

Internet-Draft              TLS Fallback SCSV              November 2013


4.  Client behavior

   The TLS_FALLBACK_SCSV cipher suite value is meant for use by clients
   that repeat a connection attempt with a downgraded protocol in order
   to avoid interoperability problems with legacy servers.  This section
   specifies when to send it.

   o  If a client sends a ClientHello.client_version containing a lower
      value than the latest (highest-valued) version supported by the
      client, it SHOULD include the TLS_FALLBACK_SCSV cipher suite value
      in ClientHello.cipher_suites.  This does not apply when the client
      intends to perform an abbreviated handshake to resume a previously
      negotiated session and sets ClientHello.client_version to the
      protocol version negotiated for that session.

   Note that in the above, a protocol version is not considered
   supported by the client if it has been disabled by any applicable
   system or user settings: it is about the highest protocol version
   that the client would attempt using in a handshake, not about the
   highest protocol version implemented if its use is not actually
   enabled.  (For example, if the implementation supports TLS 1.2 but
   the user has disabled this protocol version, a TLS 1.1 handshake is
   expected and does not warrant sending TLS_FALLBACK_SCSV.)




























Moeller & Langley         Expires June 1, 2014                  [Page 6]

Internet-Draft              TLS Fallback SCSV              November 2013


5.  Security Considerations

   Section 4 does not require client implementations to send
   TLS_FALLBACK_SCSV in any particular case, it merely recommends it;
   behavior can be adapted according to the client's security needs.
   For example, during the initial deployment of a new protocol version
   (when some interoperability problems may have to be expected),
   smoothly falling back to the previous protocol version in case of
   problems may be preferrable to potentially not being able to connect
   at all: so TLS_FALLBACK_SCSV could be omitted for this particular
   protocol downgrade step.

   However, it is particularly strongly recommended to send
   TLS_FALLBACK_SCSV when downgrading to SSL 3.0 as the CBC cipher
   suites in SSL 3.0 have weaknesses that cannot be addressed by
   implementation workarounds like the remaining weaknesses in later
   (TLS) protocol versions.


































Moeller & Langley         Expires June 1, 2014                  [Page 7]

Internet-Draft              TLS Fallback SCSV              November 2013


6.  References

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
              RFC 2246, January 1999.

   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1", RFC 4346, April 2006.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

6.2.  Informal References

   [RFC6101]  Freier, A., Karlton, P., and P. Kocher, "The Secure
              Sockets Layer (SSL) Protocol Version 3.0", RFC 6101,
              August 2011.






























Moeller & Langley         Expires June 1, 2014                  [Page 8]

Internet-Draft              TLS Fallback SCSV              November 2013


Appendix A.  Acknowledgements

   This specification was inspired by an earlier proposal by Eric
   Rescorla.















































Moeller & Langley         Expires June 1, 2014                  [Page 9]

Internet-Draft              TLS Fallback SCSV              November 2013


Authors' Addresses

   Bodo Moeller
   Google Switzerland GmbH
   Brandschenkestrasse 110
   Zurich  8002
   Switzerland

   Email: bmoeller@acm.org


   Adam Langley
   Google Inc.
   76 9th Ave
   New York, NY  10011
   USA

   Email: agl@google.com

































Moeller & Langley         Expires June 1, 2014                 [Page 10]


 DV SSL OV Сертификаты подтверждающие только Домен OV SSL OV Сертификаты подтверждающие Домен и Организацию EV SSL EV Зеленые усиленные сертификаты с указанием названия Организации подтверждают Домен и Организацию WC SSL wildcard Сертификаты защищающие все субдомены. Класс DV OV и EV SAN SSL SAN Мульти доменные  сертификаты защищающие несколько FQDN Доменов. Класс DV OV и EV PRO SSL SGC PRO сертификаты с технологией  Server Gated Cryptography. Класс  OV и EV CodeSign Сертификаты для подписи приложений и програмного кода MS, Java. Класс  OV и EV Email Сертификаты для подписи емаил smime. Класс  DV OV PDF Сертификаты для подписи документов PDF. Класс  OV PV Wi-Fi Сертификаты DigiCert для IoT и Wi Fi IoT Сертификаты DigiCert для IIoT ALL Все сертификаты Symantec Familie: Symantec, thawte, GeoTrust, DigiCert Купить сертификат

NO russia - мы не осблуживаем резидентов из россии Copyright © 1997-2018 adgrafics