Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #6280 > unrolled thread

PHP mysql_excape but need to search for those items

Back to article view | Back to comp.lang.php

Contents

  PHP mysql_excape but need to search for those items mrgushi <mrgushi@gmail.com> - 2012-06-11 08:34 -0700
    Re: PHP mysql_excape but need to search for those items Arno Welzel <usenet@arnowelzel.de> - 2012-06-11 17:54 +0200
      Re: PHP mysql_excape but need to search for those items mrgushi <mrgushi@gmail.com> - 2012-06-11 09:48 -0700
        Re: PHP mysql_excape but need to search for those items Arno Welzel <usenet@arnowelzel.de> - 2012-06-12 11:26 +0200
    Re: PHP mysql_excape but need to search for those items Jerry Stuckle <jstucklex@attglobal.net> - 2012-06-11 12:38 -0400
      Re: PHP mysql_excape but need to search for those items mrgushi <mrgushi@gmail.com> - 2012-06-11 10:01 -0700
        Re: PHP mysql_excape but need to search for those items Jerry Stuckle <jstucklex@attglobal.net> - 2012-06-11 13:54 -0400
          Re: PHP mysql_excape but need to search for those items "J.O. Aho" <user@example.net> - 2012-06-11 20:38 +0200
            Re: PHP mysql_excape but need to search for those items Jerry Stuckle <jstucklex@attglobal.net> - 2012-06-11 17:06 -0400
              Re: PHP mysql_excape but need to search for those items Arno Welzel <usenet@arnowelzel.de> - 2012-06-12 11:35 +0200
                Re: PHP mysql_excape but need to search for those items Jerry Stuckle <jstucklex@attglobal.net> - 2012-06-12 08:00 -0400
                  Re: PHP mysql_excape but need to search for those items Arno Welzel <usenet@arnowelzel.de> - 2012-06-14 08:47 +0200
                    Re: PHP mysql_excape but need to search for those items Jerry Stuckle <jstucklex@attglobal.net> - 2012-06-14 07:40 -0400
                      Re: PHP mysql_excape but need to search for those items Arno Welzel <usenet@arnowelzel.de> - 2012-06-15 22:36 +0200
                        Re: PHP mysql_excape but need to search for those items Jerry Stuckle <jstucklex@attglobal.net> - 2012-06-15 21:07 -0400
                          Re: PHP mysql_excape but need to search for those items Arno Welzel <usenet@arnowelzel.de> - 2012-06-16 08:33 +0200
                            Re: PHP mysql_excape but need to search for those items Jerry Stuckle <jstucklex@attglobal.net> - 2012-06-16 09:25 -0400
                              Re: PHP mysql_excape but need to search for those items Arno Welzel <usenet@arnowelzel.de> - 2012-06-18 09:39 +0200
                                Re: PHP mysql_excape but need to search for those items Jerry Stuckle <jstucklex@attglobal.net> - 2012-06-18 08:48 -0400
                                  Re: PHP mysql_excape but need to search for those items Arno Welzel <usenet@arnowelzel.de> - 2012-06-18 19:30 +0200
                                    Re: PHP mysql_excape but need to search for those items Jerry Stuckle <jstucklex@attglobal.net> - 2012-06-18 13:41 -0400
                                      Re: PHP mysql_excape but need to search for those items Arno Welzel <usenet@arnowelzel.de> - 2012-06-18 19:49 +0200
                                        Re: PHP mysql_excape but need to search for those items Jerry Stuckle <jstucklex@attglobal.net> - 2012-06-18 15:10 -0400
                                      Re: PHP mysql_excape but need to search for those items Michael Fesser <netizen@gmx.de> - 2012-06-18 20:21 +0200
                                        Re: PHP mysql_excape but need to search for those items Jerry Stuckle <jstucklex@attglobal.net> - 2012-06-18 15:11 -0400
                                          Re: PHP mysql_excape but need to search for those items Michael Fesser <netizen@gmx.de> - 2012-06-18 21:34 +0200
                                            Re: PHP mysql_excape but need to search for those items Jerry Stuckle <jstucklex@attglobal.net> - 2012-06-18 17:22 -0400
                                            Re: PHP mysql_excape but need to search for those items Arno Welzel <usenet@arnowelzel.de> - 2012-06-19 15:36 +0200
                                              Re: PHP mysql_excape but need to search for those items Jerry Stuckle <jstucklex@attglobal.net> - 2012-06-19 10:41 -0400
                                                Re: PHP mysql_excape but need to search for those items Arno Welzel <usenet@arnowelzel.de> - 2012-06-19 17:34 +0200
                                                  Re: PHP mysql_excape but need to search for those items Jerry Stuckle <jstucklex@attglobal.net> - 2012-06-19 12:35 -0400
                                                    Re: PHP mysql_excape but need to search for those items Arno Welzel <usenet@arnowelzel.de> - 2012-06-19 18:39 +0200
        Re: PHP mysql_excape but need to search for those items Arno Welzel <usenet@arnowelzel.de> - 2012-06-12 11:32 +0200
    Re: PHP mysql_excape but need to search for those items "Álvaro G. Vicario" <alvaro.NOSPAMTHANX@demogracia.com.invalid> - 2012-06-12 09:38 +0200

Page 1 of 2  [1] 2  Next page →

#6280 — PHP mysql_excape but need to search for those items

Hey Guys,
First time poster here. I'm working on an App that needs to be able to
querry my DB via PHP in particular those items such as periods commas
slashes and things that mysql_real_escape_string cleans out to prevent
SQL injection attacks. How would you recommend doing that securely? My
SQL login rights in the script are read only is that enough?

I was thinking of using JS to modify the querry before they hit the
mysql_real_escape_string such that I have a custom DB lookup for each
major punctuation... A period = punc1 A comma = punc2 etc.... Any
Alternate thoughts would be appreciated.
THX

PS- My app is a English Translation guide to Braille so I need to be
able to lookup punctuation in the DB somehow.

[toc] | [next] | [standalone]

#6281

Am 11.06.2012 17:34, schrieb mrgushi:

> First time poster here. I'm working on an App that needs to be able to
> querry my DB via PHP in particular those items such as periods commas
> slashes and things that mysql_real_escape_string cleans out to prevent
> SQL injection attacks. How would you recommend doing that securely? My
> SQL login rights in the script are read only is that enough?

Consider using prepared statements - the query contains placeholders for 
the parameters and all input from outside is used as parameters and is 
never directly inserted into the statement.

> I was thinking of using JS to modify the querry before they hit the
> mysql_real_escape_string such that I have a custom DB lookup for each
> major punctuation... A period = punc1 A comma = punc2 etc.... Any

An attacker can just turn off JS or use tools like curl or wget to send 
HTTP requests. So - always make sure, you server side code is secure and 
does not rely on client side scripting.


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

[toc] | [prev] | [next] | [standalone]

#6283

Interesting... Thx.
You have any samples codes to give me an idea of how something like
that would work. The JS issue is a fantastic point but not as
important as you might think. The WebApp will be embeded into a
PhoneGap Install and then locked to a HTTPS encrypted tunnel to the
PHP scripts up in the cloud.. Haven't figured out exactly how to lock
it except to use cookies with a https flag.

[toc] | [prev] | [next] | [standalone]

#6301

mrgushi, 11.06.2012 18:48:

> Interesting... Thx.
> You have any samples codes to give me an idea of how something like
> that would work. The JS issue is a fantastic point but not as

I assume you can use the mysqli extension and we have a table named
"lookuptable" where you want to get a result (id, data) for a specified
key, which was passed as GET parameter "key":

<?php
// Check, if GET parameter "key" is set
if(!isset($_GET['key']))
{
  echo 'Parameter missing';
  exit();
}

// Open database connection
$db = new mysqli('host', 'username', 'password', 'db');

// Handle connection error
if(mysqli_connect_errno())
{
  echo 'Database connection failed: '.mysqli_connect_errno();
  exit();
}

// Prepare SELECT statement with a placeholder (?) for the key
$stmt = $db->prepare('SELECT id, data FROM lookuptable WHERE key=?');

if($stmt)
{
  // Bind key parameter as string
  $stmt->bind_param('s', $_GET['key']);

  // Execute the statement
  $stmt->execute();

  // Bind the result columns
  $stmt->bind_result($id, $data);

  // Fetch the first row from the table
  if($stmt->fetch())
  {
    echo 'ID: '.$id.', data: '.$data;
  }

  // Close the statement
  $stmt->close();
}

// Close the database connection
$db->close();
?>

For further information see:

<http://www.php.net/manual/en/book.mysqli.php>

Or as an alternative to mysqli you can also use PDO:

<http://de.php.net/manual/en/book.pdo.php>


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

[toc] | [prev] | [next] | [standalone]

#6282

On 6/11/2012 11:34 AM, mrgushi wrote:
> Hey Guys,
> First time poster here. I'm working on an App that needs to be able to
> querry my DB via PHP in particular those items such as periods commas
> slashes and things that mysql_real_escape_string cleans out to prevent
> SQL injection attacks. How would you recommend doing that securely? My
> SQL login rights in the script are read only is that enough?
>
> I was thinking of using JS to modify the querry before they hit the
> mysql_real_escape_string such that I have a custom DB lookup for each
> major punctuation... A period = punc1 A comma = punc2 etc.... Any
> Alternate thoughts would be appreciated.
> THX
>
> PS- My app is a English Translation guide to Braille so I need to be
> able to lookup punctuation in the DB somehow.

No, it is not sufficient to make your SQL login rights read only.  That 
will prevent SQL injection from changing your database, but not 
something like dumping the database.

You should use mysql_real_escape_string() in the WHERE clause, also.  In 
fact, you should use it any time you are dealing with character data in 
the database - not only just INSERT or UPDATE operations.

You can use prepared statements also (some people prefer them), but that 
is also additional work.

And NEVER depend on JS or anything else client-side!

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#6284

Jerry,
This is what I'm working with so far.

not sure if I've escaped everything I needed too.

$ENG = mysql_real_escape_string($ENG);
$result = mysql_query("SELECT * FROM br_test WHERE ENG LIKE '$ENG' ");
$row = mysql_fetch_array( $result );

The $ENG is the input from the search form..
The JS problem is valid but then again it will be in a locked down iOS
app using PhoneGAp. An I'll be using a HTTPs tunnel to the PHP
scripts.. use some sort of cookie with a SSL flag to lock it down. So
someone could JailBreak an iOS app and dig down in my settings and
figure out the JS but I don't think that likely but ur right I want to
take every precaution.

-dw

[toc] | [prev] | [next] | [standalone]

#6285

On 6/11/2012 1:01 PM, mrgushi wrote:
> Jerry,
> This is what I'm working with so far.
>
> not sure if I've escaped everything I needed too.
>
> $ENG = mysql_real_escape_string($ENG);
> $result = mysql_query("SELECT * FROM br_test WHERE ENG LIKE '$ENG' ");
> $row = mysql_fetch_array( $result );
>
> The $ENG is the input from the search form..
> The JS problem is valid but then again it will be in a locked down iOS
> app using PhoneGAp. An I'll be using a HTTPs tunnel to the PHP
> scripts.. use some sort of cookie with a SSL flag to lock it down. So
> someone could JailBreak an iOS app and dig down in my settings and
> figure out the JS but I don't think that likely but ur right I want to
> take every precaution.
>
> -dw

Yes, that will work very nicely (although it's not considered good form 
to use SELECT * - rather select the individual columns.  It will save 
you heartache later).

There are more ways than just jailbreaking the IPhone.  There is no 
guarantee that the request even came from your app on an IPhone.  The 
request can easily be faked in any number of ways. And there's no 
guaranteed way to "lock it down" and be sure, unless you don't make it 
ever available via the internet.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#6286

Jerry Stuckle wrote:
> On 6/11/2012 1:01 PM, mrgushi wrote:
>> Jerry,
>> This is what I'm working with so far.
>>
>> not sure if I've escaped everything I needed too.
>>
>> $ENG = mysql_real_escape_string($ENG);
>> $result = mysql_query("SELECT * FROM br_test WHERE ENG LIKE '$ENG' ");
>> $row = mysql_fetch_array( $result );
>>
>> The $ENG is the input from the search form..
>> The JS problem is valid but then again it will be in a locked down iOS
>> app using PhoneGAp. An I'll be using a HTTPs tunnel to the PHP
>> scripts.. use some sort of cookie with a SSL flag to lock it down. So
>> someone could JailBreak an iOS app and dig down in my settings and
>> figure out the JS but I don't think that likely but ur right I want to
>> take every precaution.
>>
> Yes, that will work very nicely (although it's not considered good form to use
> SELECT * - rather select the individual columns. It will save you heartache
> later).
>
> There are more ways than just jailbreaking the IPhone. There is no guarantee
> that the request even came from your app on an IPhone. The request can easily
> be faked in any number of ways. And there's no guaranteed way to "lock it
> down" and be sure, unless you don't make it ever available via the internet.
>

Don't forget man in the middle, using https will not protect against that.

-- 

   //Aho

[toc] | [prev] | [next] | [standalone]

#6292

On 6/11/2012 2:38 PM, J.O. Aho wrote:
> Jerry Stuckle wrote:
>> On 6/11/2012 1:01 PM, mrgushi wrote:
>>> Jerry,
>>> This is what I'm working with so far.
>>>
>>> not sure if I've escaped everything I needed too.
>>>
>>> $ENG = mysql_real_escape_string($ENG);
>>> $result = mysql_query("SELECT * FROM br_test WHERE ENG LIKE '$ENG' ");
>>> $row = mysql_fetch_array( $result );
>>>
>>> The $ENG is the input from the search form..
>>> The JS problem is valid but then again it will be in a locked down iOS
>>> app using PhoneGAp. An I'll be using a HTTPs tunnel to the PHP
>>> scripts.. use some sort of cookie with a SSL flag to lock it down. So
>>> someone could JailBreak an iOS app and dig down in my settings and
>>> figure out the JS but I don't think that likely but ur right I want to
>>> take every precaution.
>>>
>> Yes, that will work very nicely (although it's not considered good
>> form to use
>> SELECT * - rather select the individual columns. It will save you
>> heartache
>> later).
>>
>> There are more ways than just jailbreaking the IPhone. There is no
>> guarantee
>> that the request even came from your app on an IPhone. The request can
>> easily
>> be faked in any number of ways. And there's no guaranteed way to "lock it
>> down" and be sure, unless you don't make it ever available via the
>> internet.
>>
>
> Don't forget man in the middle, using https will not protect against that.
>

Actually, it will.  HTTPS transmissions are encrypted between the client 
and the server using public/private key encryption.  That's the whole 
purpose of HTTPS.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#6303

Jerry Stuckle, 11.06.2012 23:06:

> On 6/11/2012 2:38 PM, J.O. Aho wrote:
[...]
>> Don't forget man in the middle, using https will not protect against
>> that.
> 
> Actually, it will.  HTTPS transmissions are encrypted between the client
> and the server using public/private key encryption.  That's the whole
> purpose of HTTPS.

But only if the client *only* trusts the specific certificate. Otherwise
the man in the middle can just set up a proxy which also accepts SSL
connections and provides a valid certificate. There have been a number
of broken CAs in the past which allowed virtually anyone to create
signed and "trusted" certificates for any domain


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

[toc] | [prev] | [next] | [standalone]

#6304

On 6/12/2012 5:35 AM, Arno Welzel wrote:
> Jerry Stuckle, 11.06.2012 23:06:
>
>> On 6/11/2012 2:38 PM, J.O. Aho wrote:
> [...]
>>> Don't forget man in the middle, using https will not protect against
>>> that.
>>
>> Actually, it will.  HTTPS transmissions are encrypted between the client
>> and the server using public/private key encryption.  That's the whole
>> purpose of HTTPS.
>
> But only if the client *only* trusts the specific certificate. Otherwise
> the man in the middle can just set up a proxy which also accepts SSL
> connections and provides a valid certificate. There have been a number
> of broken CAs in the past which allowed virtually anyone to create
> signed and "trusted" certificates for any domain
>
>

Setting up a proxy would mean alternations to the domain name servers 
data.  Additionally, the certificate either would not match the domain 
name or the certificate would not be signed by a recognized authority 
(which is a good reason to use a trusted certificate).

I don't know of any broken CAs in the past, but there could have been. 
However, the ones I use won't issue a certificate just to anyone.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#6324

Jerry Stuckle, 12.06.2012 14:00:

> On 6/12/2012 5:35 AM, Arno Welzel wrote:
>> Jerry Stuckle, 11.06.2012 23:06:
>>
>>> On 6/11/2012 2:38 PM, J.O. Aho wrote:
>> [...]
>>>> Don't forget man in the middle, using https will not protect against
>>>> that.
>>>
>>> Actually, it will.  HTTPS transmissions are encrypted between the client
>>> and the server using public/private key encryption.  That's the whole
>>> purpose of HTTPS.
>>
>> But only if the client *only* trusts the specific certificate. Otherwise
>> the man in the middle can just set up a proxy which also accepts SSL
>> connections and provides a valid certificate. There have been a number
>> of broken CAs in the past which allowed virtually anyone to create
>> signed and "trusted" certificates for any domain
> 
> Setting up a proxy would mean alternations to the domain name servers
> data.  Additionally, the certificate either would not match the domain
> name or the certificate would not be signed by a recognized authority
> (which is a good reason to use a trusted certificate).

Nameservers can be compromised - e.g. by cache poisoning.

> I don't know of any broken CAs in the past, but there could have been.
> However, the ones I use won't issue a certificate just to anyone.

And these are?

Just as a reminder: DigiNotar, Comodo, RSA - just to name a few who
already got compromised.

Also see:

<http://blogs.comodo.com/it-security/data-security/the-recent-ra-compromise/>

<http://www.itscolumn.com/2011/09/certificate-authority-hacked-google-faced-mitm-attack/>

The whole model of trusting CAs and not single certificates (as in SSH)
must be considered broken.


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

[toc] | [prev] | [next] | [standalone]

#6326

On 6/14/2012 2:47 AM, Arno Welzel wrote:
> Jerry Stuckle, 12.06.2012 14:00:
>
>> On 6/12/2012 5:35 AM, Arno Welzel wrote:
>>> Jerry Stuckle, 11.06.2012 23:06:
>>>
>>>> On 6/11/2012 2:38 PM, J.O. Aho wrote:
>>> [...]
>>>>> Don't forget man in the middle, using https will not protect against
>>>>> that.
>>>>
>>>> Actually, it will.  HTTPS transmissions are encrypted between the client
>>>> and the server using public/private key encryption.  That's the whole
>>>> purpose of HTTPS.
>>>
>>> But only if the client *only* trusts the specific certificate. Otherwise
>>> the man in the middle can just set up a proxy which also accepts SSL
>>> connections and provides a valid certificate. There have been a number
>>> of broken CAs in the past which allowed virtually anyone to create
>>> signed and "trusted" certificates for any domain
>>
>> Setting up a proxy would mean alternations to the domain name servers
>> data.  Additionally, the certificate either would not match the domain
>> name or the certificate would not be signed by a recognized authority
>> (which is a good reason to use a trusted certificate).
>
> Nameservers can be compromised - e.g. by cache poisoning.
>

And exactly how often has that occurred?  And who has the tools to do it?

>> I don't know of any broken CAs in the past, but there could have been.
>> However, the ones I use won't issue a certificate just to anyone.
>
> And these are?
>

Thwate, for one.  Verisign for another.

> Just as a reminder: DigiNotar, Comodo, RSA - just to name a few who
> already got compromised.
>
> Also see:
>
> <http://blogs.comodo.com/it-security/data-security/the-recent-ra-compromise/>
>
> <http://www.itscolumn.com/2011/09/certificate-authority-hacked-google-faced-mitm-attack/>
>
> The whole model of trusting CAs and not single certificates (as in SSH)
> must be considered broken.
>
>

And you have a better solution?

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#6337

Jerry Stuckle, 14.06.2012 13:40:

> On 6/14/2012 2:47 AM, Arno Welzel wrote:
>> Jerry Stuckle, 12.06.2012 14:00:
[...]
>>> Setting up a proxy would mean alternations to the domain name servers
>>> data.  Additionally, the certificate either would not match the domain
>>> name or the certificate would not be signed by a recognized authority
>>> (which is a good reason to use a trusted certificate).
>>
>> Nameservers can be compromised - e.g. by cache poisoning.
>>
> 
> And exactly how often has that occurred?  And who has the tools to do it?

To read more about: <http://www.kb.cert.org/vuls/id/800113>

Just because you can not imagine that his happens in reality does not
mean that you can ignore the problem.

I must admit that this problem is well known now for about 4 years and
hopefully anyone who's responsible for a nameserver did solve this - but
i mentioned it to show that "security" is not just "i use SSL, this i
secure".

>>> I don't know of any broken CAs in the past, but there could have been.
>>> However, the ones I use won't issue a certificate just to anyone.
>>
>> And these are?
>>
> 
> Thwate, for one.  Verisign for another.

VeriSign is also on the list of the CAs which had at least one security
problem:

<http://www.reuters.com/article/2012/02/02/us-hacking-verisign-idUSTRE8110Z820120202>

Of course they will never tell you about any details and of course you
shall believe that everything is perfectly fine.

And not to forget:

<http://www.thetechherald.com/articles/DigiNotar-security-incident-goes-from-bad-to-worse>

"In total, 531 fraudulent certificates were issued during the DigiNotar
breach, including certificates for Google, Microsoft, MI6, the CIA, TOR,
Mossad, Skype, Twitter, Facebook, Thawte, VeriSign, and Comodo."

Do you still believe, the CA system is trustworthy?

>> Just as a reminder: DigiNotar, Comodo, RSA - just to name a few who
>> already got compromised.
>>
>> Also see:
>>
>> <http://blogs.comodo.com/it-security/data-security/the-recent-ra-compromise/>
>>
>>
>> <http://www.itscolumn.com/2011/09/certificate-authority-hacked-google-faced-mitm-attack/>
>>
>>
>> The whole model of trusting CAs and not single certificates (as in SSH)
>> must be considered broken.
> 
> And you have a better solution?

As i already said: Don't trust a CA, only trust (or don't trust) the
certificate. If it changes your browser will immediately tell you - even
if it was signed by a CA.


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

[toc] | [prev] | [next] | [standalone]

#6341

On 6/15/2012 4:36 PM, Arno Welzel wrote:
> Jerry Stuckle, 14.06.2012 13:40:
>
>> On 6/14/2012 2:47 AM, Arno Welzel wrote:
>>> Jerry Stuckle, 12.06.2012 14:00:
> [...]
>>>> Setting up a proxy would mean alternations to the domain name servers
>>>> data.  Additionally, the certificate either would not match the domain
>>>> name or the certificate would not be signed by a recognized authority
>>>> (which is a good reason to use a trusted certificate).
>>>
>>> Nameservers can be compromised - e.g. by cache poisoning.
>>>
>>
>> And exactly how often has that occurred?  And who has the tools to do it?
>
> To read more about:<http://www.kb.cert.org/vuls/id/800113>
>
> Just because you can not imagine that his happens in reality does not
> mean that you can ignore the problem.
>

Quite frankly, I don't believe everything I see on the web.  Do you have 
any proof this has actually occurred?

> I must admit that this problem is well known now for about 4 years and
> hopefully anyone who's responsible for a nameserver did solve this - but
> i mentioned it to show that "security" is not just "i use SSL, this i
> secure".
>

Again - do you have proof any of this has actually occurred?

>>>> I don't know of any broken CAs in the past, but there could have been.
>>>> However, the ones I use won't issue a certificate just to anyone.
>>>
>>> And these are?
>>>
>>
>> Thwate, for one.  Verisign for another.
>
> VeriSign is also on the list of the CAs which had at least one security
> problem:
>
> <http://www.reuters.com/article/2012/02/02/us-hacking-verisign-idUSTRE8110Z820120202>
>
> Of course they will never tell you about any details and of course you
> shall believe that everything is perfectly fine.
>
> And not to forget:
>
> <http://www.thetechherald.com/articles/DigiNotar-security-incident-goes-from-bad-to-worse>
>
> "In total, 531 fraudulent certificates were issued during the DigiNotar
> breach, including certificates for Google, Microsoft, MI6, the CIA, TOR,
> Mossad, Skype, Twitter, Facebook, Thawte, VeriSign, and Comodo."
>
> Do you still believe, the CA system is trustworthy?
>

Again, I don't believe everything I see on the Internet.   But I have 
used both Thawte and Versign, and know what a company has to go through 
to get a certificate.

Again, do you have any proof any of this has occurred?  Or just a web 
site which claims such?

>>> Just as a reminder: DigiNotar, Comodo, RSA - just to name a few who
>>> already got compromised.
>>>
>>> Also see:
>>>
>>> <http://blogs.comodo.com/it-security/data-security/the-recent-ra-compromise/>
>>>
>>>
>>> <http://www.itscolumn.com/2011/09/certificate-authority-hacked-google-faced-mitm-attack/>
>>>
>>>
>>> The whole model of trusting CAs and not single certificates (as in SSH)
>>> must be considered broken.
>>
>> And you have a better solution?
>
> As i already said: Don't trust a CA, only trust (or don't trust) the
> certificate. If it changes your browser will immediately tell you - even
> if it was signed by a CA.
>
>

So, what is your solution?  Just telling someone not to trust a CA is 
not a solution.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#6342

Jerry Stuckle, 16.06.2012 03:07:

> On 6/15/2012 4:36 PM, Arno Welzel wrote:
>>
[...]
>> To read more about:<http://www.kb.cert.org/vuls/id/800113>
>>
>> Just because you can not imagine that his happens in reality does not
>> mean that you can ignore the problem.
>>
> 
> Quite frankly, I don't believe everything I see on the web.  Do you have
> any proof this has actually occurred?

A well documented security hole does not exist for you, as long as
nothing worse happens to you?

["Trustworthy" CAs]
>> VeriSign is also on the list of the CAs which had at least one security
>> problem:
>>
>> <http://www.reuters.com/article/2012/02/02/us-hacking-verisign-idUSTRE8110Z820120202>
[...]
>> <http://www.thetechherald.com/articles/DigiNotar-security-incident-goes-from-bad-to-worse>
[...]
> Again, I don't believe everything I see on the Internet.   But I have
> used both Thawte and Versign, and know what a company has to go through
> to get a certificate.

I know as well what it takes to get a SSL certificate signed by
VeriSign. Not much... generally just money.

On what base do you trust VeriSign or Thawte?

[...]
>> As i already said: Don't trust a CA, only trust (or don't trust) the
>> certificate. If it changes your browser will immediately tell you - even
>> if it was signed by a CA.
> 
> So, what is your solution?  Just telling someone not to trust a CA is
> not a solution.

That *is* the solution, if the CA is not trustworthy.


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

[toc] | [prev] | [next] | [standalone]

#6343

On 6/16/2012 2:33 AM, Arno Welzel wrote:
> Jerry Stuckle, 16.06.2012 03:07:
>
>> On 6/15/2012 4:36 PM, Arno Welzel wrote:
>>>
> [...]
>>> To read more about:<http://www.kb.cert.org/vuls/id/800113>
>>>
>>> Just because you can not imagine that his happens in reality does not
>>> mean that you can ignore the problem.
>>>
>>
>> Quite frankly, I don't believe everything I see on the web.  Do you have
>> any proof this has actually occurred?
>
> A well documented security hole does not exist for you, as long as
> nothing worse happens to you?
>

Sure - but how "open" is this security hole?  How easy is it to take 
advantage of?

You can say the same thing about 256 bit encryption.  It's not secure - 
it can be hacked.  However, it would take all the computers in the world 
longer than the universe has existed to hack it.

Or every time I leave my house, there is the security risk that someone 
will break in and take everything.  So I guess I should never leave my 
house.

The fact is, "security holes" exist all around us.  Just because the 
possibility exists does not mean it is a vulnerability to be concerned 
about.

These holes require the hacker be able to execute a specific pattern of 
steps, which can easily be detected and prevented, as the cert.org 
article stated.  This patter can easily be detected and prevented.  And 
all of these security holes have had patches available for 4 years.  No, 
I don't consider these security holes to be significant.

> ["Trustworthy" CAs]
>>> VeriSign is also on the list of the CAs which had at least one security
>>> problem:
>>>
>>> <http://www.reuters.com/article/2012/02/02/us-hacking-verisign-idUSTRE8110Z820120202>
> [...]
>>> <http://www.thetechherald.com/articles/DigiNotar-security-incident-goes-from-bad-to-worse>
> [...]
>> Again, I don't believe everything I see on the Internet.   But I have
>> used both Thawte and Versign, and know what a company has to go through
>> to get a certificate.
>
> I know as well what it takes to get a SSL certificate signed by
> VeriSign. Not much... generally just money.
>
> On what base do you trust VeriSign or Thawte?
>

I trust them because I have several clients with their certificates. 
And it takes a lot more than just money to get the first certificate. 
Renewals aren't bad, because you already have proven who you are previously.

> [...]
>>> As i already said: Don't trust a CA, only trust (or don't trust) the
>>> certificate. If it changes your browser will immediately tell you - even
>>> if it was signed by a CA.
>>
>> So, what is your solution?  Just telling someone not to trust a CA is
>> not a solution.
>
> That *is* the solution, if the CA is not trustworthy.
>
>

That is not a solution.  But you don't have one.  All you can do is piss 
and moan.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#6357

Jerry Stuckle, 16.06.2012 15:25:

>> Jerry Stuckle, 16.06.2012 03:07:
>>
[...]
>>> So, what is your solution?  Just telling someone not to trust a CA is
>>> not a solution.
>>
>> That *is* the solution, if the CA is not trustworthy.
> 
> That is not a solution.  But you don't have one.  All you can do is piss
> and moan.

EOD... you don't get it.


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

[toc] | [prev] | [next] | [standalone]

#6363

On 6/18/2012 3:39 AM, Arno Welzel wrote:
> Jerry Stuckle, 16.06.2012 15:25:
>
>>> Jerry Stuckle, 16.06.2012 03:07:
>>>
> [...]
>>>> So, what is your solution?  Just telling someone not to trust a CA is
>>>> not a solution.
>>>
>>> That *is* the solution, if the CA is not trustworthy.
>>
>> That is not a solution.  But you don't have one.  All you can do is piss
>> and moan.
>
> EOD... you don't get it.
>
>

I get it.  You don't have a solution, so you restate the problem, 
calling it a solution.

Just telling someone not to trust a CA is not a solution.

And BTW - I see you never responded to my proof that Verisign is a good 
authority.  If they are so untrusted, you should have no problem getting 
a certificate for something like bankofamerica.com.  I'd love to see you 
do that.  Then you'll have proof that they can't be trusted.

Otherwise you're just full of hot air.

Oh, and I see you also ignored my pointing out that the DNS system you 
say is so untrusted has never been hacked like you claim it could be - 
and that the patches to fix this hole are 4 years old.  If the DNS 
system is as full of holes as you claim, why hasn't it been hacked?

No, you're just full of hot air.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#6365

Jerry Stuckle, 18.06.2012 14:48:

[...]
> No, you're just full of hot air.

JFTR:

| I'm sorry to have to inform you that your message could not
| be delivered to one or more recipients. It's attached below.
|
| For further assistance, please send mail to postmaster.
|
| If you do so, please include this problem report. You can
| delete your own text from the attached returned message.
|
|                    The mail system
|
| <jstucklex@attglobal.net>: host mx1.prserv.net[12.154.55.40] said: 551
not our
|     customer (in reply to RCPT TO command)

At least you should use the TLD .invalid if you don't want e-mail.

And you offer service for customers? Oh my... m(


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.php

csiph-web