Changeset 4f2c988 in mod_gnutls


Ignore:
Timestamp:
Jan 24, 2020, 3:53:19 PM (3 years ago)
Author:
Fiona Klute <fiona.klute@…>
Branches:
asyncio, main, master, proxy-ticket
Children:
44188aa
Parents:
4fe52e6
Message:

Send 403 if required client post-handshake authentication fails

This is the (presumed) expected behavior if the initial handshake was
allowed and part of the server is accessible to the client.

Files:
3 edited

Legend:

Unmodified
Added
Removed

  • src/gnutls_hooks.c

    r4fe52e6 r4f2c988  
    14991499        }
    15001500
     1501        /* The request mode sent to the client is always "request"
     1502         * because if reauth with "require" fails GnuTLS invalidates
     1503         * the session, so we couldn't send 403 to the client. */
    15011504        gnutls_certificate_server_set_request(ctxt->session,
    1502                                               client_verify_mode);
     1505                                              GNUTLS_CERT_REQUEST);
    15031506        int rv = mgs_reauth(ctxt, r);
    15041507        if (rv != GNUTLS_E_SUCCESS) {

  • test/tests/35_client_reauth/apache.conf

    r4fe52e6 r4f2c988  
    55
    66<Directory ${srcdir}/data/secret>
    7  Options +ExecCGI
     7    Options +ExecCGI
    88</Directory>
    99

  • test/tests/35_client_reauth/test.yml

    r4fe52e6 r4f2c988  
    1 !connection
    2 description: >-
    3   There's no authentication needed on handshake, but the server will
    4   require reauth to serve the second request.
    5 gnutls_params:
    6   - x509cafile=authority/x509.pem
    7   - x509keyfile=authority/client/secret.key
    8   - x509certfile=authority/client/x509.pem
    9   - post-handshake-auth
    10 actions:
    11   - !request
    12     path: /test.txt
    13     expect:
    14       status: 200
    15       body:
    16         exactly: |
    17           test
    18   - !request
    19     method: POST
    20     path: /secret/mirror.cgi
    21     body: |
    22       GNUTLS_E_GOT_APPLICATION_DATA can (randomly, depending on
    23       timing) happen with a request containing a body. According to
    24       https://tools.ietf.org/html/rfc8446#appendix-E.1.2
    25       post-handshake authentication proves that the authenticated
    26       party is the one that did the handshake, so caching the data
    27       is appropriate.
    28     expect:
    29       status: 200
    30       body:
    31         exactly: |
    32           GNUTLS_E_GOT_APPLICATION_DATA can (randomly, depending on
    33           timing) happen with a request containing a body. According to
    34           https://tools.ietf.org/html/rfc8446#appendix-E.1.2
    35           post-handshake authentication proves that the authenticated
    36           party is the one that did the handshake, so caching the data
    37           is appropriate.
    38   - !request
    39     method: GET
    40     path: /secret/test.txt
    41     expect:
    42       status: 200
    43       body:
    44         exactly: |
    45           top secret
     1- !connection
     2  description: >-
     3    There's no authentication needed on handshake, but the server will
     4    require reauth to serve the second request.
     5  gnutls_params:
     6    - x509cafile=authority/x509.pem
     7    - x509keyfile=authority/client/secret.key
     8    - x509certfile=authority/client/x509.pem
     9    - post-handshake-auth
     10  actions:
     11    - !request
     12      path: /test.txt
     13      expect:
     14        status: 200
     15        body:
     16          exactly: |
     17            test
     18    - !request
     19      method: POST
     20      path: /secret/mirror.cgi
     21      body: |
     22        GNUTLS_E_GOT_APPLICATION_DATA can (randomly, depending on
     23        timing) happen with a request containing a body. According to
     24        https://tools.ietf.org/html/rfc8446#appendix-E.1.2
     25        post-handshake authentication proves that the authenticated
     26        party is the one that did the handshake, so caching the data
     27        is appropriate.
     28      expect:
     29        status: 200
     30        body:
     31          exactly: |
     32            GNUTLS_E_GOT_APPLICATION_DATA can (randomly, depending on
     33            timing) happen with a request containing a body. According to
     34            https://tools.ietf.org/html/rfc8446#appendix-E.1.2
     35            post-handshake authentication proves that the authenticated
     36            party is the one that did the handshake, so caching the data
     37            is appropriate.
     38- !connection
     39  description: >-
     40    This client has no certificate, so the the second request will
     41    receive 403 Forbidden.
     42  gnutls_params:
     43    - x509cafile=authority/x509.pem
     44    - post-handshake-auth
     45  actions:
     46    - !request
     47      path: /test.txt
     48      expect:
     49        status: 200
     50        body:
     51          exactly: |
     52            test
     53    - !request
     54      method: GET
     55      path: /secret/test.txt
     56      expect:
     57        status: 403
     58        body:
     59          contains: Forbidden
Note: See TracChangeset for help on using the changeset viewer.