On Thu, May 6, 2010 at 8:44 AM, <[email protected]> wrote:
<meta="encrypt" pubkey="ABABAEFEF2626EFEFEF"
pubtool="EC256-AES|RSA2048-AES"
passsalt="no|domainname" auth="verisign">
Good observations Frank & Ash & Aryeh & others,
I see a few shortcomings in this approach:
a) each document is encrypted asymmetrically, affecting performance.
1) yes, that's partially true. What is asymmetrically encrypted is
the keys to symmetrical encryption; which is much faster
2) no, that is not required. if user agent stores the AES password
e.g. inside a session cookie, "beyond the login page" the web-pages
can have meta-encrypt-tag pubtool="cookie-AES".
==> thus when UA requests page, server requests a cookie named
according to meta-encrypt pubkey="_value_".
==> that cookie named _value_ contains the symmetrical AES key
==> so, server sees the UA has a proper pubkey
==> server encrypts the page using symmetrical AES and sends it to UA
3) no, that's not required for the passsalt="no|domainname" argument.
salting happens only in UAs, passsalt argument is a hint to browser
to hash the password field before submitting it to server. server
would treat the salted password as any normal 'properly randomized'
password.
b) there is no management of keys (expiration, revocation, trust, etc).
1) IF auth is used, CA can validate pubkey belonging to site until xx/yy/zzzz
Browser can remember authentication and store
'SHA256(domainname)','pubkey','validuntil'
2) IF external auth is not used site can generate it's own key pair ,
using some
w3c? accepted / authenticated key generator tool, and the
webmaster then just
puts the public key into meta-encrypt tag and the private key
into... server
accessable location maybe .htpasswd file
3) ...so Dear Watsons... as the browser sees the meta-encrypt tag it (*may* be
configured) to contact CA and validate the pubkey belonging to site using
all the formal https validation techniques... What is left to the webmaster
is to insert a simple meta-encrypt tag
c) the values for the pubtool attribute (encryption algorithm) will need to
be spec'd, slowing the deployment of new encryption algorithms (or better
techniques altogether).
1) yes, that's true, some specsing is needed as there are competing
PKI technologies, with small key sizes, elliptic curves good
candidates as they are well studied and at least to sufficient degree
patent free. Initial specsing has also been done e.g. by "the OpenSSL
team accepted an ECC patch in 2005", Also NSA may provide helpful
'ideas'
http://en.wikipedia.org/wiki/ECC_patents
http://www.nsa.gov/business/programs/elliptic_curve.shtml
d) how to handle XMLHttpRequests? how to handle XHRs receiving JSON or text?
1) I'm sure you'll find a solution ;)
e) information from the UA to the server is plaintext (e.g.,
logon/passwords). If, instead, authentication relies only on possession of
the user's private key; then, any human can sit at the user's console and
automatically authenticate to all HTTP servers.
1) 'meta-encrypt'- tag encrypts only from UA -> server. IF there is a
meta-encrypt tag on a requested page, UA encrypts URI-request the form
parameters it sends to server using the pubkey="" public key
2) submits the browser's own pubkey to the server inside
each page-request to the server. the 'UA-encrypt' field may be valid only
for a session. if a page has a 'meta-encrypt'-tag and a browser has
a 'UA-encrypt'-field, the server
+) can generate a AES256 key and encrypt the page using it
+) return the requested AES256 _encrypted_ page to UA, but the
pages first line is a PKI encrypted message containing the AES256 key
that opens the 'page'
+) UA notices the BEGIN-ENC-MESSAGE......END-ENC-MESSAGE on the first line
+) UA tries it's own session private key to ENC-MESSAGE, opens
the message,
reads the AES256 key
+) UA opens the page using the AES256, and shows the page content
as any web page
3) UA gets all page content in from requested URL in fully encrypted
form server gets all the POST/GET parameters (from UA) to the page in
fully encrypted form
4) if page had a passsalt="no|domainname" form-field with or without
the 'meta-encrypt'-tag, UA hashes the password field with SHA256 and
submits the SHA256(password+domainname) to the server instead of plain
text password.
I'd prefer a radically different approach (TLS = out of scope).
There certainly are many technically excellent solutions. My approach
just focuses in and can
a) make it maximally easy and usable for 'typical' webmasters to use
b) and force the passwords salted; thus preemptively preventing id-thefts
Ash,
You're quite right, what I am suggesting is a server module which may
be on/off.
- if the meta-encrypt module is off, server module doesn't read the
page before submitting it.
- if the meta-encrypt module is off, the UA still sees e.g. <meta
encrypt passsalt="no|domainname"/> and the UA can salt the
form-password field
- if the meta-encrypt module is off, UA receives the page content without the
BEGIN-ENC-MESSAGE......END-ENC-MESSAGE on the first line, and yet
the UA *sees* the meta-encrypt-tag on page, thus the UA concludes
server's meta-encrypt module is off. So if a page visitor wants to
fill a form on a page, before submitting the GET/POST parameters to
server, UA pops up a screen
/////////////////////
Receiving site has it's encryption engine
turned off. Do you still want to submit
data to that site, as unencrypted plain
text data?
|YES| |NO|
//////////////////////
- Obviously a server must read the data chunks from a hard disk or
similar before it can submit those.
A server _module_ would be given e.g. two first 4096 byte chunks
from certain file types (html,htm,php). Module would check if there is
meta-encrypt tag (or </head>).
- if meta-encrypt was not found but </head> would be
==> module would return 0,
and apache/IIS would submit the page unencrypted
- if meta-encrypt was found
==> module would return 1, and apache would hand over
the whole file to module as well as the UA's public key
==> module would encrypt file and return it to apache
so it could be sent to UA. Also the module
would have parsed all the related file URLs that were
included in that original page. And module would
request apache to read the included file(s) and the
module would would encrypt them all
What you're suggesting is that web servers be set up to parse HTML
pages, or an extra server
module (like PHP) to parse HTML content.
Yes, PHP and other scripting languages are popular. If a site or a
server doesn't want to use PHP module (or meta-encrypt-module) they
can choose not to install it or they may exclude files in
(home)directories and all-subdirectories not to be using PHP-module
(or meta-encrypt-module) just
by setting it off e.g. using .htaccess file of 'apache/ISS' settings file.
1) Man-in-the-middle problem; which doesn't exists because
a) those are just academic mind games
You don't get to talk about security anymore.
I don't think "academic" is an *entirely* unfair characterization of
MITM on the web, actually.
...
In fact, do you know of *any* examples of MITM attacks being
successfully used against a public website?
I double that question. And before I generalized the internet MITM
attacks against PKIs being "academic mind game" (ok NSA & Co could
prove other vice), I googled and checked the wikipedia, if there were
any real life examples of internet MITM attacks against
unauthenticated PKIs, but no all seems to be non-internet site like
examples. Sure MITM can be done, but it's not the low hanging fruit;
that concerns most ordinary websites. AND just to tackle that
authentication problem I added the auth="verisign" parameter
We know hundred ways of how the HTTPS mediated security would easily
fail, but almost all off those would be "hacker-at-the-other-end
attacks". The real life data security problem is the identity thefts,
espionage and frauds. Where the unsalted passwords and multi-use of
same passwords play a key role as well as in minor degree, sniffing of
unencrypted traffic. Why would anyone even consider cryptographic MITM
attact for the purpose of achieving identity theft, as the
hacker/keylogger-at-the-other-end can achieve the same goal with less
effort. After all Internet is just a massive security hole, with of
without the HTTPS.
see the article at http://xkcd.com/538/
Juuso Hukkanen
www.colordev.com
