web应用，web服务器，TLS的引入，以及证书认证整理

http://en.wikipedia.org/wiki/Web_application

A web application or web app is any software that runs in a web browser. Web applications are popular due to the ubiquity of web browsers, and the convenience of using a web browser as a client, sometimes called a thin client. The ability to update and maintain web applications without distributing and installing software on potentially thousands of client computers is a key reason for their popularity, as is the inherent support for cross-platform compatibility. Common web applications include webmail, online retail sales, online auctions, wikis and many other functions.

Web applications can be considered as a specific variant of client-server software where the client software is downloaded to the client machine when visiting the relevant web page, using standard procedures such asHTTP. Client web software updates may happen each time the web page is visited. During the session, the web browser interprets and displays the pages, and acts as theuniversal client for any web application.

Common web applications include webmail, online retail sales, online auctions, wikis and many other functions.

网页邮件，在线零售，在线拍卖，维基等

Q1: web browser is like the universal client for any web application. So who is the server of web application? when authentication, what has been authenticated? How is TLS used?

A1：web application的服务器是web server, 认证问题在Q3中解答，TLS是为了保护http的通信。

http://en.wikipedia.org/wiki/Web_server

A web server is an information technology that processes requests via HTTP, the basic network protocol used to distribute information on the World Wide Web.

The primary function of a web server is to store, process and deliver web pages to clients. The communication between client and server takes place using the Hypertext Transfer Protocol (HTTP). Pages delivered are most frequently HTML documents, which may include images, style sheets and scripts in addition to text content.

A user agent, commonly a web browser or web crawler(网络爬虫), initiates communication by making a request for a specific resource using HTTP and the server responds with the content of that resource or anerror message if unable to do so. The resource is typically a real file on the server'ssecondary storage, but this is not necessarily the case and depends on how the web server isimplemented.

 

http://en.wikipedia.org/wiki/HTTP_Secure

HTTPS ("HTTP over TLS",^[1][2] "HTTP over SSL",^[3] or "HTTP Secure"^[4][5]) is a communications protocol for secure communication over a computer network, with especially wide deployment on the Internet. Technically, it is not a protocol in and of itself; rather, it is the result of simplylayering the Hypertext Transfer Protocol (HTTP) on top of theSSL or TLS protocol, thus adding the security capabilities of SSL/TLS to standard HTTP communications. The main motivation for HTTPS is to provideauthentication of the visited website and prevent wiretapping and man-in-the-middle attacks.

Web browsers know how to trust HTTPS websites based on certificate authorities that come pre-installed in their software.

Q2：why say "most web applications relies on the classical Diffie-Hellman and RSA-based ciphersuites of TLS" (TLS-PSK, PKC2014, p1)

A2: 因为web application都运行在web browser中，而web browser通过http向web server请求资源，TLS用于保护http数据，而一般的web应用都用标准的tls,因此有上述结论。

http://en.wikipedia.org/wiki/Thin_client

A thin client (sometimes also called a lean,zero or slim client) is a computer or a computer program that depends heavily on another computer (its server) to fulfill its computational roles. This is different from the traditionalfat client, which is a computer designed to take on these roles by itself. The specific roles assumed by the server may vary, from providingdata persistence (for example, for diskless nodes) to actual information processing on the client's behalf.Thin clients occur as components of a broader computer infrastructure, where many clients share their computations with the same server. As such, thin client infrastructures can be viewed as providing some computing service via several user interfaces. This is desirable in contexts where individual fat clients have much more functionality or power than the infrastructure requires.Thin-client computing is also a way of easily maintaining computational services at a reduced total cost of ownership.^[1]The most common type of modern thin client is a low-endcomputer terminal which only provides a graphical user interface - or more recently, in some cases, a web browser - to the end user.

 

Q3：TLS如何认证服务器和/或客户的？证书如何实现认证的？

rfc 5246 7.4.2 Server Certificate

When this message will be sent:

      The server MUST send a Certificate message whenever the agreed-upon key exchange method uses certificates for authentication (this includes all key exchange methods defined in this document except DH_anon).  This message will always immediately follow the ServerHello message.

   Meaning of this message:

      This message conveys the server's certificate chain to the client. The certificate MUST be appropriate for the negotiated ciphersuite's key exchange algorithm and any negotiated extensions.

     certificate_list
      This is a sequence (chain) of certificates.  The sender's certificate MUST come first in the list.  Each following certificate MUST directly certify the one preceding it.  Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certificate authority MAY be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case.

   The same message type and structure will be used for the client's response to a certificate request message.  Note that a client MAY send no certificates if it does not have an appropriate certificate to send in response to the server's authentication request.

Note: PKCS #7 [PKCS7] is not used as the format for the certificate vector because PKCS #6 [PKCS6] extended certificates are not used. Also, PKCS #7 defines a SET rather than a SEQUENCE, making the task of parsing the list more difficult.

   The following rules apply to the certificates sent by the server:

   -  The certificate type MUST be X.509v3, unless explicitly negotiated otherwise (e.g., [TLSPGP]).

   -  The end entity certificate's public key (and associated restrictions) MUST be compatible with the selected key exchange algorithm.

      Key Exchange Alg.  Certificate Key Type

      RSA                 RSA public key; the certificate MUST allow the key to be used for encryption (the keyEncipherment bit MUST be set if the key usage extension is present).
      RSA_PSK         Note: RSA_PSK is defined in [TLSPSK].                                         

      DHE_RSA        RSA public key; the certificate MUST allow the key to be used for signing (the digitalSignature bit MUST be set if the key usage extension is present) with    

                              the signature scheme and hash algorithm that will be employed in the server key exchange message.
                        
      ECDHE_RSA    Note: ECDHE_RSA is defined in [TLSECC].                     

      DHE_DSS         DSA public key; the certificate MUST allow the key to be used for signing with the hash algorithm that will be employed
                         
                               in the server key exchange message.      

      DH_DSS             Diffie-Hellman public key; the keyAgreement bit
      DH_RSA             MUST be set if the key usage extension is present.

      ECDH_ECDSA     ECDH-capable public key; the public key MUST
      ECDH_RSA           use a curve and point format supported by the client, as described in [TLSECC].

      ECDHE_ECDSA        ECDSA-capable public key; the certificate MUST
                         allow the key to be used for signing with the
                         hash algorithm that will be employed in the
                         server key exchange message.  The public key
                         MUST use a curve and point format supported by
                         the client, as described in  [TLSECC].

so what is X.509 [RFC 5280]

In cryptography, X.509 is an ITU-T standard for a public key infrastructure (PKI) and Privilege Management Infrastructure (PMI). X.509 specifies, amongst other things, standard formats forpublic key certificates, certificate revocation lists, attribute certificates, and a certification path validation algorithm.

The structure of an X.509 v3 digital certificate is as follows:

• Certificate
  • Version
  • Serial Number
  • Algorithm ID
  • Issuer
  • Validity
    • Not Before
    • Not After
  • Subject
  • Subject Public Key Info
    • Public Key Algorithm
    • Subject Public Key
  • Issuer Unique Identifier (optional)
  • Subject Unique Identifier (optional)
  • Extensions (optional)
    • ...
• Certificate Signature Algorithm
• Certificate Signature

http://security.stackexchange.com/questions/81972/what-part-of-tls-specifies-how-to-verify-a-certificate-chain

Note, though, that while SSL/TLS formally relies on X.509 certificates, the protocol is not irremediably married with X.509. Within the handshake dynamics,the idea is that the server sends its public key to the client within acertificate chain, and then the client somehow uses the server's public key. How the client obtains the server's public key is a bit out of scope; normally, the client does so by decoding and validating the certificate chain sent by the server, but the client is free to "know" the server's public key from any other way that it sees fit. In some dedicated applications (especially embedded systems), the client may contain a hardcoded copy of the server's public key, and just use that, completely disregarding whatever the server sends as "certificate chain".

Moreover, the "certificate chain", from the point of view of SSL/TLS, is a sequence of opaque blobs, such that the total length does not exceed 16 megabytes. While these blobs are normally encoded X.509 certificates, they may be something else, as long as the client agrees (and a client who ignores the server certificate chain will, by definition, agree to anything). There is even a formally definedRFC for using OpenPGP keys instead of X.509 certificates in SSL/TLS.

IF the certificate chain follows the usual rules (X.509 certificates, that the client validate), then theX.509 rules apply. The complete X.509 path validation algorithm isa work of the Devil to confuse and corrupt good men's minds. However, as a simple summary, an issued certificate (your "intermediate CA certificate") matches its issuer (in your case, the root) through the two following properties, which must all be fulfilled:

• The subjectDN field in the issuer (root) must be equal to theissuerDN field in the issued (intermediate CA). Thanks to the multitude of possible encodings and Byzantine Unicode rules for case matching, actual "equality" of names is a potentially complex notion.

• A certificate is signed; the signature on the issued certificate must be verifiable with regards to the issuer's public key.

 http://en.wikipedia.org/wiki/X.509

Protocols and standards supporting X.509 certificates

• TLS/SSL
• S/MIME (Secure Multipurpose Internet Mail Extensions)
• IPsec
• SSH
• Smart card
• HTTPS
• EAP
• LDAP
• Trusted Computing Group (TNC TPM NGSCB)
• CableLabs (North American Cable Industry Technology Forum)
• WS-Security
• XMPP
• Microsoft Authenticode
• OPC UA