SSL info

Hi Folks,

I'm going to be working with some SSL pages (php) and wondered if there
were any good design/development sites for security tips etc so I miss
out on making the "obvious" blunders - whatever they may be.

I've found: http://blogs.msdn.com/ie/archive/2005/04/20/410240.aspx
which is very good and lists two possible problems. Here then is the
newbie question.

If a form is hosted on a HTTP (non secure) site and points to a HTTPS
in the action tag, does this mean that the page has already made the
SSL connection/handshake? Does the browser recognise the potential for
a HTTPS connection and therefore do the same as if it was a full SSL
page?

Secondly, why is mixed content so bad (any sites would be great)? I
appreciate various elements could be secure/unsecure but how would that
pose a risk?

Thanks

UkUsEr

"UKuser" <spidercc21@yahoo.co.uk> writes:
> I'm going to be working with some SSL pages (php) and wondered if there
> were any good design/development sites for security tips etc so I miss
> out on making the "obvious" blunders - whatever they may be.
>
> I've found: http://blogs.msdn.com/ie/archive/2005/04/20/410240.aspx
> which is very good and lists two possible problems. Here then is the
> newbie question.
>
> If a form is hosted on a HTTP (non secure) site and points to a HTTPS
> in the action tag, does this mean that the page has already made the
> SSL connection/handshake? Does the browser recognise the potential for
> a HTTPS connection and therefore do the same as if it was a full SSL
> page?
>
> Secondly, why is mixed content so bad (any sites would be great)? I
> appreciate various elements could be secure/unsecure but how would that
> pose a risk?

originally SSL was suppose to address two issues 1) are you really
talking to the server that you think you are talking to and 2)
encryption (hiding) of transmitted information.

for #1, the user typed in the URL of the server they wanted to talk
to, the server returned a SSL domain name server digital certificate,
the browser validated the digital certificate and then compared the
domain name in the user supplied URL with the domain name in the
digital certificate.

some posts about working on this long ago and far away with a
small client/server startup that wanted to do payment transactions
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

they had this technology called SSL ... and the payment transaction
processing has since come to be called e-commerce. some number
of past posts mentioning SSL processing
http://www.garlic.com/~lynn/subpubkey.html#sslcert

fairly quickly a problem cropped up ... merchants discovered that
using SSL for the complete processing cut their processing thruput by
80-90percent ... so they restricted SSL for just the checkout/payment
processing. So now a user enters a non-SSL URL ... which doesn't check
to see that the server that the user is talking to, is really the
server that the user thinks they are talking to.

the users click on a server provided button ... which supplies the
(SSL) URL. In this situation ... rather than checking that the server
is the server the user thinks they are talking to ... the only thing
it does is checks that the server is whoever they claim to be
(i.e. the server provides both the URL with a domain name as well as
the digital certificate with the domain name). it would take a fairly
inexperienced to claim to be one server and not be able to provide a
digital certificate that substantiates that claim. this is also what
is behind some of the phishing emails that can provide (SSL) URLs to
click-thru on ... where the attacker provides both the URL and any
digital certificate that supports that they are who they claim to be.

there is separate "catch-22" scenario that certification authorities
are looking at for improving the integrity of the domain name digital
certificates that they issue. currently they require a lot of
identification information as to the applicant for the digital
certificate. they then go thru a time-consuming, costly, and error
prone processing of cross-checking that the provided information (by
the digital certificate applicant) matches the information on-file
with the domain name infrastructure as to the owner of the specific
domain.

the proposal is for having domain name owners provide a public key to
the domain name infrastructure when they register the domain name.
now the certification authorities can require that digital certificate
applications be digitally signed. Now the certification authorities
can do a real-time retrieval of the on-file public key (from the
domain name infrastructure ... analogous to what they do now when they
do real-time retrieval of information as to the owner of the domain
name for matching) ... and use it to validate the digital
signature. This turns a time-consuming, error prone, and costly
identification matching process into a much more reliable, simple, and
less expensive authentication process.

the "catch-22" is that if the certification authority can do a
real-time retrieval of the on-file public key for digital certificate,
then potentially the rest of the world can also ... eliminating
the need for the digital certificates ... misc. past posts mentioning
the "catch-22"
http://www.garlic.com/~lynn/subpubkey.html#catch22

that can result in transition to certificateless public key operation.
misc. past posts mentioning certificateless operation
http://www.garlic.com/~lynn/subpubkey.html#certless

and reference to old email from 1981 with a suggestion for a
certificateless public key operation:
http://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network
http://www.garlic.com/~lynn/2006w.html#15 more secure communication over the network
http://www.garlic.com/~lynn/2006w.html#18 more secure communication over the network

some number of references to account-based public key operation
(as opposed to digital certificate public key operation)
http://www.garlic.com/~lynn/x959.html#aads

"UKuser" <spidercc21@yahoo.co.uk> (07-01-02 08:42:02):

> Secondly, why is mixed content so bad (any sites would be great)? I
> appreciate various elements could be secure/unsecure but how would
> that pose a risk?

I'd like to drop a note here. Others have mentioned the performance
impact coming from SSL. But this is not a problem of SSL itself. It's
a configuration problem.

Actually there is nothing wrong with running an entire site through SSL,
since you can turn on and off authentication and encryption as you like.
So you would transmit everything authenticated, but not encrypted, and
you would only encrypt the textual content.

But since most admins just hit the "Make My Connections Secure (TM)"
button on their administration web-interface, the bad performance is
natural. To properly use SSL, you really should have some background
information about public-key cryptography, and you really should
configure your HTTPd carefully by hand.

That also helps exploiting the full potential of SSL. For example, you
can't just authenticate the server, you can also authenticate the client
or anything else via a certificate. So no more username/password pairs
are needed. Users don't need to login manually, they just present their
certificate, which is straightforward in today's modern browsers.


Regards,
E.S.

Ertugrul Soeylemez <never@drwxr-xr-x.org> writes:
> That also helps exploiting the full potential of SSL. For example, you
> can't just authenticate the server, you can also authenticate the client
> or anything else via a certificate. So no more username/password pairs
> are needed. Users don't need to login manually, they just present their
> certificate, which is straightforward in today's modern browsers.

actually, client authentication/authorization can be done straight
forwardly using registered public keys and digital signatures w/o
requiring any digital certificate what-so-ever. misc. past posts
mentioning certificateless operation
http://www.garlic.com/~lynn/subpubkey.html#certless

the first place that became especially evident was when we were
brought in to do some consulting with this small client/server startup
that had this technology called SSL and wanted to do payment
transactions ... for something that has since come to be called
e-commerce. previous post in this thread:
http://www.garlic.com/~lynn/2007.html#7 SSL info

at the time SSL didn't have mutual authentication ... but we required
it for the payment gateway (the webservers authenticated the payment
gateway using installed public key ... and the payment gateway
authenticate the webservers using on-file public keys). The addition
code had to be added to SSL to do mutual authentication and since it
was already heavily certificate-based orientation there still were
digital certificates that were passed back-and-forth ... but in
actuality ... each authorized webserver had the information about the
payment gateway preloaded as part of the payment processing software
.... and the payment gateway had onfile information about each
authorized webserver. it quickly became strikenly apparent that
the digital certificates were redundant and superfluous. misc.
other posts mentioning ssl digital certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcert

so the dominant forms of client authentication in the world wide web
environments are KERBEROS and RADIUS. These started out being
userid/password. However, both KERBEROS and RADIUS have had
definitions and implementations were client public keys are registered
(in lieu of passwords), servers transmit some random information (as
countermeasure to replay attacks), and the clients (using their
private key) digitally sign and return the digital signature ... which
the server than verifies with the onfile public key.

The original KERBEROS PKINIT (public key) draft initially just
specified certificateless operation ... but under a great deal
of lobbying, certificate-mode operation was also added.

One of the scenarios for various webserver software is that client
authentication has frequently just been a stub model ... although
there are plugins for webserver software that provide kerberos and
radius interfaces for client authentication. In many of these typical
implementations ... the kerberos and radius implementations are done
in such a way that it is possible to specify password or digital
signature operation on a account by account basis ... again
certificateless operation. misc. past posts about kerberos operation
http://www.garlic.com/~lynn/subpubkey.html#kerberos
and radius operation
http://www.garlic.com/~lynn/subpubkey.html#radius

sort of the original idea for certificate-mode of operation was that
there was interaction between two parties that had no prior knowledge
of each other. it was necessary for the certificates to carry all the
necessary information. this also sort of gave rise to the x.509
identity certificates from the early 90s.

however, by the mid-90s it was realized that x.509 identity
certificates, typically heavily overloaded with personal information
represented significant privacy and liability issues. as a result,
you saw many institutions dropping back to what they called
relying-party-only certificates ... misc. past posts mentiong
RPO certificates:
http://www.garlic.com/~lynn/subpubkey.html#rpo

the issue here is that an RPO-certificate basically just carries a
public key and some sort of account number. the relying party, takes
the account number and retrieves the appropriate account record
.... where the actual personal information including any authorization
information is kept. however, since the public key originally had to
be registered and stored in an account record before any digital
certificate was issued, it was trivial to show that the relying party
retrieving the account record can include the registered public key.
Again, the digital certificate becomes redundant and superfluous.

basically the kerberos and radius PKI implementations with digital
certificates typically have done something similar as RPO-certificate,
the permission/authorization information is stored in an onfile
account record. if any of the client PKI digital certificates
authentication operations (kerberos, radius, or roll-your-own) at some
point have to retrieve any sort of account record as part of
permissions and authorizations ... it is then trivial to also show
(again) that the digital certificates are redundant and superfluous.

The digital certificate actually only has meaninful role ... when the
server never has to resort to really knowing who the client is and/or
anything about the client ... other than what is presented in the
digital certificates. No additional information related to things like
permissions, authorizations, billing, accounts, etc is required.

its like anybody with valid digital certificate can log into your
system and have all permissions regardless of who they are ... and
there is no userid account record for the system that is required to
provide any additional information related to the user and/or what the
user is allowed to do or not do.

as soon as the process has to resort to any additional information
(than what is provided in the digital certificate) for doing any
operation what-so-ever for the client ... then it is trivial to
show that the digital certificate is redundant and superfluous.

Hi Sebastian,

Thanks for the information. You're obviously assuming that an attacker
can get to the unsecured content and modify it. What would stop an
attacker accessing files on a secure area as well? If SSL just encrypts
the communication between the webserver and client, how are the SSL
files any more secure?

Thanks

A

Sebastian Gottschalk wrote:

> UKuser wrote:
>
> > I'm going to be working with some SSL pages (php) and wondered if there
> > were any good design/development sites for security tips etc so I miss
> > out on making the "obvious" blunders - whatever they may be.
>
> The obvious blunders are incompetent Root-CA s. You can easily recognize
> them: If they're claiming to be Root-CA, then they're incompetent.
>
> > I've found: http://blogs.msdn.com/ie/archive/2005/04/20/410240.aspx
> > which is very good and lists two possible problems. Here then is the
> > newbie question.
> >
> > If a form is hosted on a HTTP (non secure) site and points to a HTTPS
> > in the action tag, does this mean that the page has already made the
> > SSL connection/handshake?
>
> No.
>
> > Does the browser recognise the potential for
> > a HTTPS connection and therefore do the same as if it was a full SSL
> > page?
>
> Yes. However, this won't help if the attacker can modified the unsecure
> form to transmit the content to somewhere else.
>
> > Secondly, why is mixed content so bad (any sites would be great)? I
> > appreciate various elements could be secure/unsecure but how would that
> > pose a risk?
>
> Simple: The nonsecure content can be modified by an attacker, and such a
> modified content can also modify/overwrite/extend the secure content.
>
> Trivial example: Overwrite an nonsecure CSS stylesheet with "body {
> display:none; visible: no; content-before:<!-- put your phishing website
> here -->}"

Just want to thank everyone for their contributions. I thought
(incorrectly) this would appear under Sebastians reply.

A

UKuser wrote:

> Hi Sebastian,
>
> Thanks for the information. You're obviously assuming that an attacker
> can get to the unsecured content and modify it. What would stop an
> attacker accessing files on a secure area as well? If SSL just encrypts
> the communication between the webserver and client, how are the SSL
> files any more secure?
>
> Thanks
>
> A
>
> Sebastian Gottschalk wrote:
>
> > UKuser wrote:
> >
> > > I'm going to be working with some SSL pages (php) and wondered if there
> > > were any good design/development sites for security tips etc so I miss
> > > out on making the "obvious" blunders - whatever they may be.
> >
> > The obvious blunders are incompetent Root-CA s. You can easily recognize
> > them: If they're claiming to be Root-CA, then they're incompetent.
> >
> > > I've found: http://blogs.msdn.com/ie/archive/2005/04/20/410240.aspx
> > > which is very good and lists two possible problems. Here then is the
> > > newbie question.
> > >
> > > If a form is hosted on a HTTP (non secure) site and points to a HTTPS
> > > in the action tag, does this mean that the page has already made the
> > > SSL connection/handshake?
> >
> > No.
> >
> > > Does the browser recognise the potential for
> > > a HTTPS connection and therefore do the same as if it was a full SSL
> > > page?
> >
> > Yes. However, this won't help if the attacker can modified the unsecure
> > form to transmit the content to somewhere else.
> >
> > > Secondly, why is mixed content so bad (any sites would be great)? I
> > > appreciate various elements could be secure/unsecure but how would that
> > > pose a risk?
> >
> > Simple: The nonsecure content can be modified by an attacker, and such a
> > modified content can also modify/overwrite/extend the secure content.
> >
> > Trivial example: Overwrite an nonsecure CSS stylesheet with "body {
> > display:none; visible: no; content-before:<!-- put your phishing website
> > here -->}"

Anne & Lynn Wheeler <lynn@garlic.com> writes:
> however, by the mid-90s it was realized that x.509 identity
> certificates, typically heavily overloaded with personal information
> represented significant privacy and liability issues. as a result,
> you saw many institutions dropping back to what they called
> relying-party-only certificates ... misc. past posts mentiong
> RPO certificates:
> http://www.garlic.com/~lynn/subpubkey.html#rpo

for a little drift ... these are a couple of posts that draw the
comparison between some of the current electronic chip passports and
the x.509 identity certificates from the early 90s.
http://www.garlic.com/~lynn/aadsm25.htm#46 Flaw exploited in RFID-enabled passports
http://www.garlic.com/~lynn/aadsm26.htm#0 Flaw in RFID-enabled passports (part 2?)

using that comparison, then there is the possibility that all personal
information would be eliminated from the passport chips ... for
similar privacy and liability reasons that resulted in change-over to
relying-party-only certificates in the mid-90s (and away from x.509
identity certificates frequently overloaded with personal information)
http://www.garlic.com/~lynn/subpubkey.html#rpo

after having worked on SSL-based infrastructure ... that has since come
to be called e-commerce ... previous posts in this thread
http://www.garlic.com/~lynn/2007.html#7 SSL info
http://www.garlic.com/~lynn/2007.html#15 SSL info

we had participated in the x9a10 financial standard working group. In the
mid-90s, x9a10 had been given the requirement to preserve the integrity
of the financial infrastructure for all retail payments
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

it was in this period that we had coined the term certificate
manufactoring to differentiate the commoningly deployed SSL digital
certificate infrastructure (of the period) from "real" PKI:
http://www.garlic.com/~lynn/subpubkey.html#manufacture

it was also in this period that several people made claims that
upgrading financial transactions with client/consumer digital
certificates would bring retail financial transactions in the modern
era.

the issue here (as in the passport case) is that credentials and
certificates are constructs developed for providing trusted
information for an offline environment. in the 70s, electronic payment
networks made the transition from the offline environment to the
online environment ... and supported real-time information regarding
authentication and authorization. digital certificate-based offline
paradigm for financial transactions, rather than representing any
modernization, would result to reverting to pre-70s paradigm.

it was in this period that we also coined the term "comfort
certificates" ... the redundant and superfluous use of stale, static
digital certificates (an offline paradigm construct) in an online
environment. The "comfort certificates" provided familiarity and
comfort to mindsets that were stuck in the old fashion offline
paradigm (which required credentials and certificates to provide
trusted information distribution) ... and had difficulty making the
transition to an trusted online integrity paradigm.

our repeated observations about the offline digital certificate model
actually regressing effective operation by several decades (rather
than any modernization) was some of the motivation behind OCSP (online
certificate status protocol). However, our observation was that it was
really a rube golberg fabrication ... given any operation ... what is
more valuable: ... 1) a real time transaction involving real time
authentication and authorization information ... or 2) a real time
transaction providing status indication about stale, static digital
certificate information.

this was also the period that spawned the infrastructure that enabled
the "yes card" exploits
http://www.garlic.com/~lynn/subintegrity.html#yescard

i.e. adding chips to payment cards for use in retail transactions.
there were some number of claims that adding the chips even increased
the vulnerabilities ... compared to a similar magstripe card w/o a
chip.

Sebastian Gottschalk <seppi@seppig.de> (07-01-03 04:41:33):

> > Actually there is nothing wrong with running an entire site through
> > SSL, since you can turn on and off authentication and encryption as
> > you like. So you would transmit everything authenticated, but not
> > encrypted, and you would only encrypt the textual content.
>
> Bad idea. Who decides which part of the content is important to
> encrypt and which is not? You? A program? I doubt that anyone gets it
> right. That's why you should encrypt everything.

Yes, you should. But in situations, where this is simply not possible,
you should at least sign the traffic, which you don't encrypt. That's
my point.


> > That also helps exploiting the full potential of SSL. For example,
> > you can't just authenticate the server, you can also authenticate
> > the client or anything else via a certificate. So no more
> > username/password pairs are needed. Users don't need to login
> > manually, they just present their certificate, which is
> > straightforward in today's modern browsers.
>
> And without a PKI, this will nullify any security, since the attacker
> could easily impersonate the client.

No problem. Take the server as the CA. On registration, the user
chooses a user-name. And instead of a password, they present their
certificate (implicitly by connecting through SSL) to the server, which
the server saves and signs. Unless the client's certificate has already
been used (which would be a clear sign for compromise), the user is now
logged in, as long as he connects through SSL with that particular
certificate.

What is nice about this method is that you can use the same client
certificate for arbitrarily many sites. You can't do that with
passwords. You would have to choose a different one for each site.


Regards,
E.S.

Sebastian Gottschalk <seppi@seppig.de> (07-01-05 17:21:42):

> > > And without a PKI, this will nullify any security, since the
> > > attacker could easily impersonate the client.
> >
> > No problem. Take the server as the CA. On registration, the user
> > chooses a user-name. And instead of a password, they present their
> > certificate (implicitly by connecting through SSL) to the server,
> > which the server saves and signs. Unless the client's certificate
> > has already been used (which would be a clear sign for compromise),
> > the user is now logged in, as long as he connects through SSL with
> > that particular certificate.
>
> This is trivally prone to a man-in-the-middle attack. You really don't
> understand what out-of-bound-authentication is and why it's a
> necessity?

Taking the server as a CA implies that the clients (need to) have that
particular CA certificate. No trusted arbitrator is necessary inside of
the protocol. But there is indeed a need for one, when distributing the
CA certificate, unless this is applied to a local network, where a
secure infrastructure is already in place.


> > What is nice about this method is that you can use the same client
> > certificate for arbitrarily many sites.
>
> Nice? This is rather bad, since it reduces security and eliminates
> privacy.

I have a single GPG key pair, with which I sign for multiple email
addresses. I have a single SSH key pair, which I use to login to a lot
of sites. According to your statement, this is less secure than using a
separate key for each site and email address, and my privacy is
completely lost. Sounds odd, doesn't it?

Besides the fact that a certificate contains a bit more information,
what are the privacy implications? Unless the certificate represents
something like an electronic form of your passport, you decide, what
goes in there. When the CA decides to sign it, then they do so.
Otherwise you're free to go elsewhere.

Now to the security part: A public key, as its name states, is made
publicly available. If that does reduce security, then what's the point
in public key cryptography? The authenticator really just needs the
public key to verify authenticity. A certificate is nothing more than
an encapsulated public key, together with some informations about its
holder, and one or more signatures (at least from a CA in the proper
case).


> Where have you been when MS Passport was cracked over and over again?

I really don't care about the diseases of Microsoft implementations.
Microsoft Passport is not a PKI anyway, so what?


Regards,
E.S.

Ertugrul Soeylemez <never@drwxr-xr-x.org> writes:
> Besides the fact that a certificate contains a bit more information,
> what are the privacy implications? Unless the certificate represents
> something like an electronic form of your passport, you decide, what
> goes in there. When the CA decides to sign it, then they do so.
> Otherwise you're free to go elsewhere.
>
> Now to the security part: A public key, as its name states, is made
> publicly available. If that does reduce security, then what's the point
> in public key cryptography? The authenticator really just needs the
> public key to verify authenticity. A certificate is nothing more than
> an encapsulated public key, together with some informations about its
> holder, and one or more signatures (at least from a CA in the proper
> case).

so you have a client that generates a public/private key pair. the
client registers the public key with the server/certification
authority ... the server/ca registers the public key in the server/ca
database ... then the server/ca generates a digital certificate
containing the public key and gives a copy of the digital certificate
to the client..

now in an authentication operation, the client digital signs
something, appends the digital certificate and transmits the digital
signature and digital certificate to the server/ca ... who already has
a copy of the client's public key on-file.

since the server/ca already has a copy of the client's public
key (as part of the registration operation) ... and, in fact,
the server/ca probably even recorded the original of the client's
digital certificate. that means the server/ca not only has the
client's public key as well the client's digital certificate.

requiring the client to return a copy of the digital certificate to
the ca/server on each digital signature operation is redundant and
superfluous ... when the ca/server already has copy of the client's
public key and typically also has the client's original digital
certificate (after having sent a copy of the client's digital
certificate to the client).

the ca/server would also run much more efficiently if they just used
the onfile client's public key that they already have to verify the
client's digital signature ... rather than having to go thru the
repeated extraneous gorp of verifying the (appended transmitted)
client digital certificate along with all the related digital
certificate encoding/decoding magic.

past posts in this thread:
http://www.garlic.com/~lynn/2007.html#7 SSL info
http://www.garlic.com/~lynn/2007.html#15 SSL info
http://www.garlic.com/~lynn/2007.html#17 SSL info

as mentioned before ... one of the reasons for the retrenching from
the early 90s x.509 identity digital certificates to the
relying-party-only digital certificates in the mid-90s ... was
eliminating all the extraneous personal information. It isn't so much
the publication of public key that was the issue ... it was spraying
personal information all over the place everytime the digital
certificate was transmitted.

Reducing the digital certificate to public key and some sort of
(server) record locator ... is the relying-party-only digital
certificate
http://www.garlic.com/~lynn/subpubkey.html#rpo

however, it is straight-forward to demonstrate that it is much more
efficient and drastically simpler for the relying party to directly
retrieve the public key from an online record, eliminating all of the
client digital certificate gorp ... i.e. certificateless public key
http://www.garlic.com/~lynn/subpubkey.html#certless

so comparing simple certificateless digital signature authentication
to password authentication

1) well implemented digital signature authentication is immune from
skimming/evesdropping and replay attacks (impersonation)

2) typically password scenarios require a unique value for every
different security domain. the problem is that the same value is
used for both origination and verification. unique passwords
are countermeasure for scenarios where one domain can attack
another (i.e. local garage isp and your online banking or
your place of business).

there is huge advantage of using public keys (and digital signatures)
for authentication ... compared to pins/passwords. this is true
regardless of whether it is a certificate or certificateless paradigm.

however, sometimes there is misconception that public keys
and digital certificates are equivalent.

digital certificates are mechanism for trusted information
distribution for the offline enviornment ... somewhat the electronic
version of letters of introduction/credit from the sailing ship days
.... when two entities had no prior relations .... and the relying
party had no way of directly contacting the certifying party.

However when it becomes abundently evident that the offline paradigm
digital certificates are redundant and superfluous in an online world
.... and/or between entities that have established relationship ...
then it doesn't have to follow that there is no advantage to having
public key infrastructure (without digital certificates).

Anne & Lynn Wheeler <lynn@garlic.com> (07-01-05 21:09:35):

> [bunch of redundant non-information]

If I ask, how to dispose a car, you explain the construction ideas of
its fuel tank.


Regards,
E.S.