rfc4287.The Atom Syndication Format

Network Working Group R. Housley Request for Comments: 5652 Vigil Security Obsoletes: 3852 September 2009 Category: Standards TrackCryptographic Message Syntax (CMS)AbstractThis document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encryptarbitrary message content.Status of This MemoThis document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions forimprovements. Please refer to the current edition of the "InternetOfficial Protocol Standards" (STD 1) for the standardization stateand status of this protocol. Distribution of this memo is unlimited. Copyright and License NoticeCopyright (c) 2009 IETF Trust and the persons identified as thedocument authors. All rights reserved.This document is subject to BCP 78 and the IETF Trust’s LegalProvisions Relating to IETF Documents(/license-info) in effect on the date ofpublication of this document. Please review these documentscarefully, 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 ofthe Trust Legal Provisions and are provided without warranty asdescribed in the BSD License.This document may contain material from IETF Documents or IETFContributions published or made publicly available before November10, 2008. The person(s) controlling the copyright in some of thismaterial may not have granted the IETF Trust the right to allowmodifications of such material outside the IETF Standards Process.Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modifiedoutside the IETF Standards Process, and derivative works of it maynot be created outside the IETF Standards Process, except to formatit for publication as an RFC or to translate it into languages other than English.Housley Standards Track [Page 1]Table of Contents1. Introduction (3)1.1. Evolution of the CMS (4)1.1.1. Changes Since PKCS #7 Version 1.5 (4)1.1.2. Changes Since RFC 2630 (4)1.1.3. Changes Since RFC 3369 (5)1.1.4. Changes Since RFC 3852 (5)1.2. Terminology (5)1.3. Version Numbers (6)2. General Overview (6)3. General Syntax (7)4. Data Content Type (7)5. Signed-data Content Type (8)5.1. SignedData Type (9)5.2. EncapsulatedContentInfo Type (11)5.2.1. Compatibility with PKCS #7 (12)5.3. SignerInfo Type (13)5.4. Message Digest Calculation Process (16)5.5. Signature Generation Process (16)5.6. Signature Verification Process (17)6. Enveloped-Data Content Type (17)6.1. EnvelopedData Type (18)6.2. RecipientInfo Type (21)6.2.1. KeyTransRecipientInfo Type (22)6.2.2. KeyAgreeRecipientInfo Type (23)6.2.3. KEKRecipientInfo Type (25)6.2.4. PasswordRecipientInfo Type (26)6.2.5. OtherRecipientInfo Type (27)6.3. Content-encryption Process (27)6.4. Key-Encryption Process (28)7. Digested-Data Content Type (28)8. Encrypted-Data Content Type (29)9. Authenticated-Data Content Type (30)9.1. AuthenticatedData Type (31)9.2. MAC Generation (33)9.3. MAC Verification (34)10. Useful Types (34)10.1. Algorithm Identifier Types (35)10.1.1. DigestAlgorithmIdentifier (35)10.1.2. SignatureAlgorithmIdentifier (35)10.1.3. KeyEncryptionAlgorithmIdentifier (35)10.1.4. ContentEncryptionAlgorithmIdentifier (36)10.1.5. MessageAuthenticationCodeAlgorithm (36)10.1.6. KeyDerivationAlgorithmIdentifier (36)10.2. Other Useful Types (36)10.2.1. RevocationInfoChoices (36)10.2.2. CertificateChoices (37)Housley Standards Track [Page 2]10.2.3. CertificateSet (38)10.2.4. IssuerAndSerialNumber (38)10.2.5. CMSVersion (39)10.2.6. UserKeyingMaterial (39)10.2.7. OtherKeyAttribute (39)11. Useful Attributes (39)11.1. Content Type (40)11.2. Message Digest (40)11.3. Signing Time (41)11.4. Countersignature (42)12. ASN.1 Modules (43)12.1. CMS ASN.1 Module (44)12.2. Version 1 Attribute Certificate ASN.1 Module (51)13. References (52)13.1. Normative References (52)13.2. Informative References (53)14. Security Considerations (54)15. Acknowledgments (56)1. IntroductionThis document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encryptarbitrary message content.The CMS describes an encapsulation syntax for data protection. Itsupports digital signatures and encryption. The syntax allowsmultiple encapsulations; one encapsulation envelope can be nestedinside another. Likewise, one party can digitally sign somepreviously encapsulated data. It also allows arbitrary attributes,such as signing time, to be signed along with the message content,and it provides for other attributes such as countersignatures to be associated with a signature.The CMS can support a variety of architectures for certificate-based key management, such as the one defined by the PKIX (Public KeyInfrastructure using X.509) working group [PROFILE].The CMS values are generated using ASN.1 [X.208-88], using BER-encoding (Basic Encoding Rules) [X.209-88]. Values are typicallyrepresented as octet strings. While many systems are capable oftransmitting arbitrary octet strings reliably, it is well known that many electronic mail systems are not. This document does not address mechanisms for encoding octet strings for reliable transmission insuch environments.Housley Standards Track [Page 3]1.1. Evolution of the CMSThe CMS is derived from PKCS #7 version 1.5, which is documented inRFC 2315 [PKCS#7]. PKCS #7 version 1.5 was developed outside of the IETF; it was originally published as an RSA Laboratories TechnicalNote in November 1993. Since that time, the IETF has takenresponsibility for the development and maintenance of the CMS.Today, several important IETF Standards-Track protocols make use ofthe CMS.This section describes that changes that the IETF has made to the CMS in each of the published versions.1.1.1. Changes Since PKCS #7 Version 1.5RFC 2630 [CMS1] was the first version of the CMS on the IETFStandards Track. Wherever possible, backward compatibility with PKCS #7 version 1.5 is preserved; however, changes were made toaccommodate version 1 attribute certificate transfer and to supportalgorithm-independent key management. PKCS #7 version 1.5 includedsupport only for key transport. RFC 2630 adds support for keyagreement and previously distributed symmetric key-encryption keytechniques.1.1.2. Changes Since RFC 2630RFC 3369 [CMS2] obsoletes RFC 2630 [CMS1] and RFC 3211 [PWRI].Password-based key management is included in the CMS specification,and an extension mechanism to support new key management schemeswithout further changes to the CMS is specified. Backwardcompatibility with RFC 2630 and RFC 3211 is preserved; however,version 2 attribute certificate transfer is added, and the use ofversion 1 attribute certificates is deprecated.Secure/Multipurpose Internet Mail Extensions (S/MIME) v2 signatures[MSG2], which are based on PKCS #7 version 1.5, are compatible withS/MIME v3 signatures [MSG3]and S/MIME v3.1 signatures [MSG3.1].However, there are some subtle compatibility issues with signaturesbased on PKCS #7 version 1.5. These issues are discussed in Section 5.2.1. These issues remain with the current version of the CMS.Specific cryptographic algorithms are not discussed in this document, but they were discussed in RFC 2630. The discussion of specificcryptographic algorithms has been moved to a separate document[CMSALG]. Separation of the protocol and algorithm specificationsallows the IETF to update each document independently. Thisspecification does not require the implementation of any particular Housley Standards Track [Page 4]algorithms. Rather, protocols that rely on the CMS are expected tochoose appropriate algorithms for their environment. The algorithms may be selected from [CMSALG] or elsewhere.1.1.3. Changes Since RFC 3369RFC 3852 [CMS3] obsoletes RFC 3369 [CMS2]. As discussed in theprevious section, RFC 3369 introduced an extension mechanism tosupport new key management schemes without further changes to theCMS. RFC 3852 introduces a similar extension mechanism to supportadditional certificate formats and revocation status informationformats without further changes to the CMS. These extensions areprimarily documented in Sections 10.2.1 and 10.2.2. Backwardcompatibility with earlier versions of the CMS is preserved.The use of version numbers is described in Section 1.3.Since the publication of RFC 3369, a few errata have been noted.These errata are posted on the RFC Editor web site. These errorshave been corrected in this document.The text in Section 11.4 that describes the counter signatureunsigned attribute is clarified. Hopefully, the revised text isclearer about the portion of the SignerInfo signature that is covered by a countersignature.1.1.4. Changes Since RFC 3852This document obsoletes RFC 3852 [CMS3]. The primary reason for the publication of this document is to advance the CMS along thestandards maturity ladder.This document includes the clarifications that were originallypublished in RFC 4853 [CMSMSIG] regarding the proper handling of the SignedData protected content type when more than one digitalsignature is present.Since the publication of RFC 3852, a few errata have been noted.These errata are posted on the RFC Editor web site. These errorshave been corrected in this document.1.2. TerminologyIn this document, the key words MUST, MUST NOT, REQUIRED, SHOULD,SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted asdescribed in [STDWORDS].Housley Standards Track [Page 5]1.3. Version NumbersEach of the major data structures includes a version number as thefirst item in the data structure. The version numbers are intendedto avoid ASN.1 decode errors. Some implementations do not check the version number prior to attempting a decode, and if a decode erroroccurs, then the version number is checked as part of the errorhandling routine. This is a reasonable approach; it places errorprocessing outside of the fast path. This approach is also forgiving when an incorrect version number is used by the sender.Most of the initial version numbers were assigned in PKCS #7 version 1.5. Others were assigned when the structure was initially created. Whenever a structure is updated, a higher version number is assigned. However, to ensure maximum interoperability, the higher versionnumber is only used when the new syntax feature is employed. Thatis, the lowest version number that supports the generated syntax isused.2. General OverviewThe CMS is general enough to support many different content types.This document defines one protection content, ContentInfo.ContentInfo encapsulates a single identified content type, and theidentified type may provide further encapsulation. This documentdefines six content types: data, signed-data, enveloped-data,digested-data, encrypted-data, and authenticated-data. Additionalcontent types can be defined outside this document.An implementation that conforms to this specification MUST implement the protection content, ContentInfo, and MUST implement the data,signed-data, and enveloped-data content types. The other contenttypes MAY be implemented.As a general design philosophy, each content type permits single pass processing using indefinite-length Basic Encoding Rules (BER)encoding. Single-pass operation is especially helpful if content is large, stored on tapes, or is "piped" from another process. Single- pass operation has one significant drawback: it is difficult toperform encode operations using the Distinguished Encoding Rules(DER) [X.509-88] encoding in a single pass since the lengths of thevarious components may not be known in advance. However, signedattributes within the signed-data content type and authenticatedattributes within the authenticated-data content type need to betransmitted in DER form to ensure that recipients can verify acontent that contains one or more unrecognized attributes. Signedattributes and authenticated attributes are the only data types used in the CMS that require DER encoding.Housley Standards Track [Page 6]3. General SyntaxThe following object identifier identifies the content informationtype:id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2)us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 6 }The CMS associates a content type identifier with a content. Thesyntax MUST have ASN.1 type ContentInfo:ContentInfo ::= SEQUENCE {contentType ContentType,content [0] EXPLICIT ANY DEFINED BY contentType }ContentType ::= OBJECT IDENTIFIERThe fields of ContentInfo have the following meanings:contentType indicates the type of the associated content. It isan object identifier; it is a unique string of integers assignedby an authority that defines the content type.content is the associated content. The type of content can bedetermined uniquely by contentType. Content types for data,signed-data, enveloped-data, digested-data, encrypted-data, andauthenticated-data are defined in this document. If additionalcontent types are defined in other documents, the ASN.1 typedefined SHOULD NOT be a CHOICE type.4. Data Content TypeThe following object identifier identifies the data content type:id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2)us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }The data content type is intended to refer to arbitrary octetstrings, such as ASCII text files; the interpretation is left to the application. Such strings need not have any internal structure(although they could have their own ASN.1 definition or otherstructure).S/MIME uses id-data to identify MIME-encoded content. The use ofthis content identifier is specified in RFC 2311 for S/MIME v2[MSG2], RFC 2633 for S/MIME v3 [MSG3], and RFC 3851 for S/MIME v3.1[MSG3.1].Housley Standards Track [Page 7]The data content type is generally encapsulated in the signed-data,enveloped-data, digested-data, encrypted-data, or authenticated-data content type.5. Signed-data Content TypeThe signed-data content type consists of a content of any type andzero or more signature values. Any number of signers in parallel can sign any type of content.The typical application of the signed-data content type representsone signer’s digital signature on content of the data content type.Another typical application disseminates certificates and certificate revocation lists (CRLs).The process by which signed-data is constructed involves thefollowing steps:1. For each signer, a message digest, or hash value, is computed on the content with a signer-specific message-digest algorithm. If the signer is signing any information other than the content, the message digest of the content and the other information aredigested with the signer’s message digest algorithm (see Section 5.4), and the result becomes the "message digest."2. For each signer, the message digest is digitally signed using the signer’s private key.3. For each signer, the signature value and other signer-specificinformation are collected into a SignerInfo value, as defined in Section 5.3. Certificates and CRLs for each signer, and thosenot corresponding to any signer, are collected in this step.4. The message digest algorithms for all the signers and theSignerInfo values for all the signers are collected together with the content into a SignedData value, as defined in Section 5.1.A recipient independently computes the message digest. This message digest and the signer’s public key are used to verify the signaturevalue. The signer’s public key is referenced in one of two ways. It can be referenced by an issuer distinguished name along with anissuer-specific serial number to uniquely identify the certificatethat contains the public key. Alternatively, it can be referenced by a subject key identifier, which accommodates both certified anduncertified public keys. While not required, the signer’scertificate can be included in the SignedData certificates field. Housley Standards Track [Page 8]When more than one signature is present, the successful validation of one signature associated with a given signer is usually treated as a successful signature by that signer. However, there are someapplication environments where other rules are needed. Anapplication that employs a rule other than one valid signature foreach signer must specify those rules. Also, where simple matching of the signer identifier is not sufficient to determine whether thesignatures were generated by the same signer, the applicationspecification must describe how to determine which signatures weregenerated by the same signer. Support of different communities ofrecipients is the primary reason that signers choose to include more than one signature. For example, the signed-data content type might include signatures generated with the RSA signature algorithm andwith the Elliptic Curve Digital Signature Algorithm (ECDSA) signature algorithm. This allows recipients to verify the signature associated with one algorithm or the other.This section is divided into six parts. The first part describes the top-level type SignedData, the second part describesEncapsulatedContentInfo, the third part describes the per-signerinformation type SignerInfo, and the fourth, fifth, and sixth partsdescribe the message digest calculation, signature generation, andsignature verification processes, respectively.5.1. SignedData TypeThe following object identifier identifies the signed-data contenttype:id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }The signed-data content type shall have ASN.1 type SignedData:SignedData ::= SEQUENCE {version CMSVersion,digestAlgorithms DigestAlgorithmIdentifiers,encapContentInfo EncapsulatedContentInfo,certificates [0] IMPLICIT CertificateSet OPTIONAL,crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,signerInfos SignerInfos }DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifierSignerInfos ::= SET OF SignerInfoHousley Standards Track [Page 9]The fields of type SignedData have the following meanings:version is the syntax version number. The appropriate valuedepends on certificates, eContentType, and SignerInfo. Theversion MUST be assigned as follows:IF ((certificates is present) AND(any certificates with a type of other are present)) OR((crls is present) AND(any crls with a type of other are present))THEN version MUST be 5ELSEIF (certificates is present) AND(any version 2 attribute certificates are present)THEN version MUST be 4ELSEIF ((certificates is present) AND(any version 1 attribute certificates are present)) OR (any SignerInfo structures are version 3) OR(encapContentInfo eContentType is other than id-data) THEN version MUST be 3ELSE version MUST be 1digestAlgorithms is a collection of message digest algorithmidentifiers. There MAY be any number of elements in thecollection, including zero. Each element identifies the messagedigest algorithm, along with any associated parameters, used byone or more signer. The collection is intended to list themessage digest algorithms employed by all of the signers, in anyorder, to facilitate one-pass signature verification.Implementations MAY fail to validate signatures that use a digest algorithm that is not included in this set. The message digesting process is described in Section 5.4.encapContentInfo is the signed content, consisting of a contenttype identifier and the content itself. Details of theEncapsulatedContentInfo type are discussed in Section 5.2.certificates is a collection of certificates. It is intended that the set of certificates be sufficient to contain certificationpaths from a recognized "root" or "top-level certificationauthority" to all of the signers in the signerInfos field. There may be more certificates than necessary, and there may becertificates sufficient to contain certification paths from two or more independent top-level certification authorities. There mayalso be fewer certificates than necessary, if it is expected that recipients have an alternate means of obtaining necessaryHousley Standards Track [Page 10]certificates (e.g., from a previous set of certificates). Thesigner’s certificate MAY be included. The use of version 1attribute certificates is strongly discouraged.crls is a collection of revocation status information. It isintended that the collection contain information sufficient todetermine whether the certificates in the certificates field arevalid, but such correspondence is not necessary. Certificaterevocation lists (CRLs) are the primary source of revocationstatus information. There MAY be more CRLs than necessary, andthere MAY also be fewer CRLs than necessary.signerInfos is a collection of per-signer information. There MAY be any number of elements in the collection, including zero. When the collection represents more than one signature, the successful validation of one of signature from a given signer ought to betreated as a successful signature by that signer. However, there are some application environments where other rules are needed.The details of the SignerInfo type are discussed in Section 5.3.Since each signer can employ a different digital signaturetechnique, and future specifications could update the syntax, all implementations MUST gracefully handle unimplemented versions ofSignerInfo. Further, since all implementations will not supportevery possible signature algorithm, all implementations MUSTgracefully handle unimplemented signature algorithms when they are encountered.5.2. EncapsulatedContentInfo TypeThe content is represented in the type EncapsulatedContentInfo:EncapsulatedContentInfo ::= SEQUENCE {eContentType ContentType,eContent [0] EXPLICIT OCTET STRING OPTIONAL }ContentType ::= OBJECT IDENTIFIERThe fields of type EncapsulatedContentInfo have the followingmeanings:eContentType is an object identifier. The object identifieruniquely specifies the content type.eContent is the content itself, carried as an octet string. TheeContent need not be DER encoded.Housley Standards Track [Page 11]The optional omission of the eContent within theEncapsulatedContentInfo field makes it possible to construct"external signatures". In the case of external signatures, thecontent being signed is absent from the EncapsulatedContentInfo value included in the signed-data content type. If the eContent valuewithin EncapsulatedContentInfo is absent, then the signatureValue is calculated and the eContentType is assigned as though the eContentvalue was present.In the degenerate case where there are no signers, theEncapsulatedContentInfo value being "signed" is irrelevant. In this case, the content type within the EncapsulatedContentInfo value being "signed" MUST be id-data (as defined in Section 4), and the contentfield of the EncapsulatedContentInfo value MUST be omitted.5.2.1. Compatibility with PKCS #7This section contains a word of warning to implementers that wish to support both the CMS and PKCS #7 [PKCS#7] SignedData content types.Both the CMS and PKCS #7 identify the type of the encapsulatedcontent with an object identifier, but the ASN.1 type of the content itself is variable in PKCS #7 SignedData content type.PKCS #7 defines content as:content [0] EXPLICIT ANY DEFINED BY contentType OPTIONALThe CMS defines eContent as:eContent [0] EXPLICIT OCTET STRING OPTIONALThe CMS definition is much easier to use in most applications, and it is compatible with both S/MIME v2 and S/MIME v3. S/MIME signedmessages using the CMS and PKCS #7 are compatible because identicalsigned message formats are specified in RFC 2311 for S/MIME v2[MSG2], RFC 2633 for S/MIME v3 [MSG3], and RFC 3851 for S/MIME v3.1[MSG3.1]. S/MIME v2 encapsulates the MIME content in a Data type(that is, an OCTET STRING) carried in the SignedData contentInfocontent ANY field, and S/MIME v3 carries the MIME content in theSignedData encapContentInfo eContent OCTET STRING. Therefore, inS/MIME v2, S/MIME v3, and S/MIME v3.1, the MIME content is placed in an OCTET STRING and the message digest is computed over the identical portions of the content. That is, the message digest is computedover the octets comprising the value of the OCTET STRING, neither the tag nor length octets are included.Housley Standards Track [Page 12]There are incompatibilities between the CMS and PKCS #7 SignedDatatypes when the encapsulated content is not formatted using the Datatype. For example, when an RFC 2634 signed receipt [ESS] isencapsulated in the CMS SignedData type, then the Receipt SEQUENCE is encoded in the SignedData encapContentInfo eContent OCTET STRING and the message digest is computed using the entire Receipt SEQUENCEencoding (including tag, length and value octets). However, if anRFC 2634 signed receipt is encapsulated in the PKCS #7 SignedDatatype, then the Receipt SEQUENCE is DER encoded [X.509-88] in theSignedData contentInfo content ANY field (a SEQUENCE, not an OCTETSTRING). Therefore, the message digest is computed using only thevalue octets of the Receipt SEQUENCE encoding.The following strategy can be used to achieve backward compatibility with PKCS #7 when processing SignedData content types. If theimplementation is unable to ASN.1 decode the SignedData type usingthe CMS SignedData encapContentInfo eContent OCTET STRING syntax,then the implementation MAY attempt to decode the SignedData typeusing the PKCS #7 SignedData contentInfo content ANY syntax andcompute the message digest accordingly.The following strategy can be used to achieve backward compatibility with PKCS #7 when creating a SignedData content type in which theencapsulated content is not formatted using the Data type.Implementations MAY examine the value of the eContentType, and thenadjust the expected DER encoding of eContent based on the objectidentifier value. For example, to support Microsoft Authenticode[MSAC], the following information MAY be included:eContentType Object Identifier is set to { 1 3 6 1 4 1 311 2 1 4 } eContent contains DER-encoded Authenticode signing information5.3. SignerInfo TypePer-signer information is represented in the type SignerInfo:SignerInfo ::= SEQUENCE {version CMSVersion,sid SignerIdentifier,digestAlgorithm DigestAlgorithmIdentifier,signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,signatureAlgorithm SignatureAlgorithmIdentifier,signature SignatureValue,unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }Housley Standards Track [Page 13]。

此文档所含信息可能随时被修改，恕不另行通知，我们不保证该信息没有错误。如果贵方发现任何问题，请书面通知我们。
如果将本软件或相关文档交付给美国政府，或者交付给以美国政府名义获得许可证的任何机构，则适用以下注意事项：
U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

关于⽤vb的winsock穿透代理的讨论归讨论,⼀直没有什么源代码放出,现在我就放源出来,省的某些⼈拿这所谓的"技术"去骗钱. 由于缺乏测试环境,本程序只在我⾃⼰编写的代理模拟器上测试过,其结果和腾讯QQ,MSN,易泡泡穿越该模拟器时得出的结果基本⼀致.因此,代码可能有错误的地⽅,请各位有条件的⽤户⾃⾏改正,请见谅! ⾸先,是基础知识,也就是RFC⽂档.这个是必看内容.我的程序就是基于这些⽂档写出.下⾯是各RFC的连接,为了准确,我先提供英⽂版的连接,在下⾯的介绍中再把关键部分翻译成中⽂.另外,要纠正⼀个错误.国内很多⽂章说socks5代理的⽤户名/密码校验标准在 RFC 1928⾥有说明,其实这是⼀个完全错误的说法(我很怀疑写那⽂章的⼈有没有看过RFC),socks5⽤户名/密码校验标准其实是在 RFC 1929 ⾥⾯说明的. RFC 1928 - socks5 代理标准 RFC 1929 - socks5 代理⽤户名/密码校验标准 RFC - socks4 代理标准 RFC 2616 - HTTP1.1 标准 我们现在直⼊正题:先说socks5的TCP穿透(有了这个例⼦⼤家⾃⼰照这可以写UDP穿透) ⾸先和代理服务器连接-直接⽤winsock去connect指定的地址端⼝(通常是1080)即可.然后进⼊细节商议阶段. 细节商议--⽆⽤户名/密码校验 RFC 1928 中对于细节商议的第⼀步是这样描述的: The client connects to the server, and sends a version identifier/method selection message: +----+----------+----------+ |VER | NMETHODS | METHODS | +----+----------+----------+ | 1 | 1 | 1 to 255 | +----+----------+----------+ The VER field is set to X'05' for this version of the protocol. The NMETHODS field contains the number of method identifier octets that appear in the METHODS field. The server selects from one of the methods given in METHODS, and sends a METHOD selection message: +----+--------+ |VER | METHOD | +----+--------+ | 1 | 1 | +----+--------+ If the selected METHOD is X'FF', none of the methods listed by the client are acceptable, and the client MUST close the connection. The values currently defined for METHOD are: o X'00' NO AUTHENTICATION REQUIRED ---------⽆⽤户密码 00 o X'01' GSSAPI --------- GSSAPI ? o X'02' USERNAME/PASSWORD ---------有⽤户密码 02 o X'03' to X'7F' IANA ASSIGNED o X'80' to X'FE' RESERVED FOR PRIVATE METHODS o X'FF' NO ACCEPTABLE METHODS ---------失败 255 The client and server then enter a method-specific sub-negotiation.。

学习网络常用的RFC文档的名称双语RFC --RFC中英文对照版rfc1050中文版-远程过程调用协议规范rfc1055中文版-在串行线路上传输IP数据报的非标准协议rfc1057中文版-RFC:远程过程调用协议说明第二版rfc1058中文版-路由信息协议（Routing Information Protocol）rfc1073中文版-RFC1073 Telnet窗口尺寸选项rfc1075中文版-远距离矢量多播选路协议rfc1088中文版-在NetBIOS网络上传输IP数据报的标准rfc1090中文版-SMTP在X.25上rfc1091中文版-TELNET终端类型选项rfc1094中文版-RFC1094 网络文件系统协议rfc1096中文版-Telnet X显示定位选项rfc1097中文版-Telnet潜意识-信息选项rfc1112中文版-主机扩展用于IP多点传送rfc1113中文版-Internet电子邮件保密增强：Part1-消息编码和鉴别过程rfc1132中文版-802．2分组在IPX网络上传输的标准rfc1144中文版-低速串行链路上的TCP/IP头部压缩rfc1155中文版-基于TCP/IP网络的管理结构和标记rfc1191中文版-RFC1191 路径MTU发现rfc1332中文版-RFC1332 端对端协议网间协议控制协议（IPCP）rfc1333中文版-PPP 链路质量监控rfc1334中文版-PPP 身份验证协议rfc1387中文版-RIP（版本2）协议分析rfc1388中文版-RIP协议版本2rfc1433中文版-直接ARPrfc1445中文版-SNMPv2的管理模型rfc1582中文版-扩展RIP以支持按需链路rfc1618中文版-ISDN上的PPP(点对点)协议rfc1661中文版-RFC1661 PPP协议rfc1723中文版-路由信息协议（版本2）rfc1738中文版-统一资源定位器（URL）rfc1769中文版-简单网络时间协议( SNTP)rfc1771中文版-边界网关协议版本4（BGP-4）rfc1827中文版-IP封装安全载荷（ESP）rfc1883中文版-Internet协议，版本6（IPv6）说明书rfc1939中文版-POP3协议rfc1945中文版-超文本传输协议 -- HTTP/1.0rfc1994中文版-PPP挑战握手认证协议(CHAP)rfc1997中文版-RFC1997 BGP团体属性rfc2002中文版-IP移动性支持rfc204中文版-利用报路rfc2105中文版-Cisco 系统的标签交换体系结构纵览rfc2281中文版-Cisco热备份路由协议（）rfc2283中文版-BGP-4的多协议扩展rfc2326中文版-实时流协议(RTSP)rfc2328中文版-OSPF版本2rfc2516中文版-在以太网上传输PPP的方法（PPPoE）rfc2526中文版-IPv6保留的子网任意传送地址rfc2547中文版-BGP/MPLS VPNsrfc2616中文版-超文本传输协议——HTTP/1.1rfc2702中文版-基于MPLS的流量工程要求rfc2706中文版-RFC2706—电子商务域名标准rfc2756中文版-超文本缓存协议(HTCP/0.0)rfc2764中文版-IP VPN的框架体系rfc2773中文版-使用KEA和SKIPJACK加密rfc2774中文版-HTTP扩展框架rfc2781中文版-UTF-16, 一种ISO 10646的编码方式rfc2784中文版-通用路由封装rfc2793中文版-用于文本交谈的RTP负载rfc2796中文版-BGP路由反射rfc2917中文版-核心 MPLSIP VPN 体系结构rfc2918中文版-BGP-4（边界网关协议）的路由刷新功能rfc2923中文版-TCP的路径MTU发现问题rfc3003中文版-Audio/mpeg 媒体类型rfc3005中文版-IETF 讨论列表许可证rfc3007中文版-安全的域名系统动态更新rfc3018中文版-统一内存空间协议规范rfc3022中文版-传统IP网络地址转换（传统NAT）rfc3032中文版-RFC3032 MPLS标记栈编码rfc3033中文版-用于Internet协议的信息域和协议标识符在Q.2941类属标识符和Q.2957 User-to-user信令中的分配rfc3034中文版-标签转换在帧中继网络说明书中的使用rfc3037中文版-RFC3037 标记分配协议的适用范围（RFC3037 LDP Applicability）rfc3058中文版-IDEA加密算法在CMS上的使用rfc3059中文版-服务定位协议的属性列表扩展rfc3061中文版-对象标识符的一种URN姓名空间rfc3062中文版-LDAP口令修改扩展操作rfc3063中文版-MPLS（多协议标签交换）环路预防机制rfc3066中文版-语言鉴定标签rfc3067中文版-事件对象描述和转换格式要求rfc3069中文版-VLAN聚合实现IP地址有效分配rfc3070中文版-基于帧中继的第二层隧道协议rfc3072中文版-结构化数据交换格式rfc3074中文版-DHCP 负载平衡算法rfc3078中文版-RFC3078微软点到点加密(MPPE)协议rfc3081中文版-将区块扩展交换协议（BEEP）核心映射到传输控制协议（TCP）rfc3083中文版-遵循DOCSIS的Cable Modem和CMTS的PBI 的管理信息数据库rfc3085中文版-新闻型标记语言（NewsML）资源的URN名字空间rfc3090中文版-域名系统在区域状况下的安全扩展声明rfc3091中文版-Pi数字生成协议rfc3093中文版-防火墙增强协议rfc3550中文版-RTP：实时应用程序传输协议rfc457中文版-TIPUGrfc697中文版-FTP的CWD命令rfc698中文版-TELNET扩展ASCII选项rfc775中文版-面向目录的 FTP 命令rfc779中文版-TELNET的SEND-LOCATION选项rfc792中文版-RFC792- Internet控制信息协议（ICMP）rfc821中文版-RFC821 简单邮件传输协议（SMTP）rfc826中文版-以太网地址转换协议或转换网络协议地址为48比特以太网地址用于在以太网硬件上传输rfc854中文版-TELNET协议规范rfc855中文版-TELNET选项规范rfc856中文版-RFC856 TELNET二进制传输rfc857中文版-RFC 857 TELNET ECHO选项rfc858中文版-RFC 858 TELNET SUPPRESS GO AHEAD选项rfc859中文版-RFC 859 TELNET的STATUS选项rfc860中文版-RFC 860 TELNET TIMING MARK选项rfc861中文版-RFC 861 TELNET扩展选项-LISTrfc862中文版-RFC 862 Echo 协议rfc868中文版-RFC868 时间协议rfc894中文版-IP 数据包通过以太网网络传输标准rfc903中文版-反向地址转换协议rfc930中文版-Telnet终端类型选项（RFC930——T elnet Terminal Type Option）rfc932中文版-子网地址分配方案rfc937中文版-邮局协议 (版本2)rfc948中文版-IP数据报通过IEEE802.3网络传输的两种方法rfc949中文版-FTP 未公开的独特命令rfc951中文版-引导协议(BOOTP)rfc962中文版-TCP-4 的最初rfc974中文版-邮件路由与域名系统rfc975中文版-自治联邦。