Re: http+aes

Le 5 mars 2012 à 05:21, Julian Reschke a écrit :
> FYI:
> 	http://dev.w3.org/html5/spec/Overview.html#http-aes-scheme


A better link (or less browser killing) ;)
http://dev.w3.org/html5/spec/iana.html#http-aes-scheme

And the text (This is revision 1.5603. Editor's Draft 5 March 2012)

    12.6 http+aes scheme

    This section describes a URL scheme registration for the IANA URI
    scheme registry. [RFC4395]

    URI scheme name:
        http+aes

    Status:
        permanent

    URI scheme syntax:
        Same as http, with the userinfo component instead used for
        specifying the decryption key. (This key is provided in the form
        of 16, 24, or 32 bytes encoded as ASCII and escaped as necessary
        using the URL escape mechanism; it is not in the
        "username:password" form, and the ":" character is not special
        in this component when using this scheme.)

    URI scheme semantics:
        Same as http, except that the message body must be decrypted by
        applying the AES-CTR algorithm using the key specified in the
        URL's userinfo component, after unescaping it from the URL
        syntax to bytes. If there is no such component, or if that
        component, when unescaped from the URL syntax to bytes, does not
        consist of exactly 16, 24, or 32 bytes, then the user agent must
        act as if the resource could not be obtained due to a network
        error, and may report the problem to the user.

    Encoding considerations:
        Same as http, but the userinfo component represents bytes
        encoded using ASCII and the URL escape mechanism.

    Applications/protocols that use this URI scheme name:
        Same as http.

    Interoperability considerations:
        Same as http, but specifically for private resources that are
        hosted by untrusted intermediary servers as in a content
        delivery network.

    Security considerations:

        URLs using this scheme contain sensitive information (the key
        used to decrypt the referenced content) and as such should be
        handled with care, e.g. only sent over TLS-encrypted
        connections, and only sent to users who are authorized to access
        the encrypted content.

        User agents are encouraged to not show the key in user
        interface elements where the URL is displayed: first, it's
        ugly and not useful to the user; and second, it could be
        used to obscure the domain name.

        The http+aes URL scheme only enables the content of a
        particular resource to be encrypted. Any sensitive
        information held in HTTP headers is still transmitted in the
        clear. The length of the resource is still visible. The rate
        at which the data is transmitted is also unobscured. The
        name of the resource is not hidden. If this scheme is used
        to obscure private information, it is important to consider
        how these side channels might leak information.

            For example, the length of a file containing only
            the user's age in seconds encoded in ASCII would
            easily let an attacker watching the network traffic
            or with access to the system hosting the files
            determine if the user was less than 3 years old,
            less than 30 years old, or more than 30 years old,
            just from the length of the file. Padding the file
            to ten digits (either with trailing spaces or
            leading zeros) would make all ages from zero to
            three hundred indistinguishable.

            Another example would be the file name. Consider a
            bank where each user first downloads a "data.json"
            file, which points to some other files for more
            data, such that users in debt download a "debt.json"
            file while users in credit download a "credit.json"
            file. In such a scenario, users can be categorised
            by an attacker watching network traffic or with
            access to the system hosting the files without the
            attacker ever having to decrypt the "data.json"
            files.

        The security considerations that apply to http apply as well.
    Contact:
        Ian Hickson <ian@hixie.ch>
    Author/Change controller:
        Ian Hickson <ian@hixie.ch>
    References:
         The http URL scheme is defined in: http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging

-- 
Karl Dubost - http://dev.opera.com/
Developer Relations, Opera Software

Received on Monday, 5 March 2012 13:17:21 UTC