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

Groups > comp.arch > #3220 > unrolled thread

Somewhat off-topic: comp-arch.net cloned, possibly hacked

Back to article view | Back to comp.arch

Contents

  Somewhat off-topic: comp-arch.net cloned, possibly hacked "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-08-28 19:49 -0700
    Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked EricP <ThatWouldBeTelling@thevillage.com> - 2011-08-28 23:32 -0400
    Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked EricP <ThatWouldBeTelling@thevillage.com> - 2011-08-28 23:49 -0400
      Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-08-29 08:59 -0700
        Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked EricP <ThatWouldBeTelling@thevillage.com> - 2011-08-29 12:40 -0400
          Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-08-29 12:00 -0700
          Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-08-29 12:00 -0700
            Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked George Neuner <gneuner2@comcast.net> - 2011-08-29 21:31 -0400
            Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked Anne & Lynn Wheeler <lynn@garlic.com> - 2011-08-29 22:12 -0400
              Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked Anne & Lynn Wheeler <lynn@garlic.com> - 2011-08-30 09:38 -0400
              Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked Anne & Lynn Wheeler <lynn@garlic.com> - 2011-08-30 10:51 -0400
            Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-08-30 13:53 +0200
              Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-08-30 06:59 -0700
                Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked Anne & Lynn Wheeler <lynn@garlic.com> - 2011-08-30 10:23 -0400
                  Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked kenney@cix.compulink.co.uk - 2011-08-31 08:04 -0500
                    Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked Anne & Lynn Wheeler <lynn@garlic.com> - 2011-08-31 10:26 -0400
                    Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked nmm1@cam.ac.uk - 2011-08-31 18:58 +0100
                Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked nmm1@cam.ac.uk - 2011-08-30 14:58 +0100
                Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-08-31 10:25 +0200
                  Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked Anne & Lynn Wheeler <lynn@garlic.com> - 2011-08-31 10:01 -0400
                    Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked Anne & Lynn Wheeler <lynn@garlic.com> - 2011-08-31 12:15 -0400
      Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-08-29 08:59 -0700

Page 1 of 2  [1] 2  Next page →

#3220 — Somewhat off-topic: comp-arch.net cloned, possibly hacked

Apologies if this is somewhat off-topic for comp.arch,
but

(1) y'all may refer me to better plavces

(2) this may be a useful warning to some of you who may have 
occasionally used my comp-arch.net wensite.

===

Googling "glew FP16" today, I found my own website, comp-arch.net.

But I also found another website, waboba.info, that seems to be a clone 
of comp-arch.net.

This is probably a malware site, probably directing people to attack 
code, or at least trying to promote search engine scores.

It is certainly unauthorized. I.e. nobody asked me about setting it up/

It is probably a violation of the very loose copyright and licensing 
setup for comp-arch.net - a derivative of Creative Commons.

In a way, it is flattering that compo-arch.net might be considered worth 
cloning.  But then again, I imagine that this sort of thing is automated 
by the bad guys.

If you ever use comp-arch.net stuff, beware of waboba.info, and other 
possible clones.

--

If anyone here has advice on steps to take, Id appreciate it.

===

Of more concern is the fact that my copyright notice,
https://semipublic.comp-arch.net/wiki/index.php?title=CompArch:Copyrights_and_Other_Intellectual_Property_Rights,
seems to have disappeared.

Now, this may have happened for innocuous reasons - such as an automatic 
update of the underlying mediawiki version.

But, it may also indicate that my site has been hacked.
If only to legitimize the unauthorized cloning described above.

I will investigate 0 bt that may take a while.

---

The real problem here is that I spend very little time working on this 
site, and I want to spend that time writing content, not administering 
Mediawiki.

I may need to give in and use a hosted wiki.

[toc] | [next] | [standalone]

#3221

Andy "Krazy" Glew wrote:
> 
> But I also found another website, waboba.info, that seems to be a clone 
> of comp-arch.net.

Connecting to INFO.whois-servers.net...

Domain ID:D28811262-LRMS
Domain Name:WABOBA.INFO
Created On:17-Jun-2009 16:26:11 UTC
Last Updated On:19-Jul-2011 10:16:57 UTC
Expiration Date:17-Jun-2012 16:26:11 UTC
Sponsoring Registrar:Tucows Inc. (R139-LRMS)
Status:CLIENT TRANSFER PROHIBITED
Status:CLIENT UPDATE PROHIBITED
Registrant ID:tuCuB2bz5jHShWw0
Registrant Name:Krzysztof Giska
Registrant Organization:"TooTu...skrot do sukcesu..."
Registrant Street1:ZNIWNA 4/8
Registrant Street2:
Registrant Street3:
Registrant City:LODZ
Registrant State/Province:
Registrant Postal Code:94-250
Registrant Country:PL
Registrant Phone:+48.426370264
Registrant Phone Ext.:
Registrant FAX:
Registrant FAX Ext.:
Registrant Email:biuro@tootu.pl
Admin ID:tu9Z9QqJ82Fzz3qa
Admin Name:Administracja Sieci home.pl
Admin Organization:home.pl
Admin Street1:plac Rodla 9
Admin Street2:
Admin Street3:
Admin City:Szczecin
Admin State/Province:
Admin Postal Code:70-419
Admin Country:PL
Admin Phone:+48.914325555
Admin Phone Ext.:
Admin FAX:
Admin FAX Ext.:
Admin Email:dns@home.pl
Billing ID:tuUgU71oFFJx8WOV
Billing Name:Administracja Sieci home.pl
Billing Organization:home.pl
Billing Street1:plac Rodla 9
Billing Street2:
Billing Street3:
Billing City:Szczecin
Billing State/Province:
Billing Postal Code:70-419
Billing Country:PL
Billing Phone:+48.914325555
Billing Phone Ext.:
Billing FAX:
Billing FAX Ext.:
Billing Email:dns@home.pl
Tech ID:tuYaKPep9Q7Mv8OD
Tech Name:Administracja Sieci home.pl
Tech Organization:home.pl
Tech Street1:plac Rodla 9
Tech Street2:
Tech Street3:
Tech City:Szczecin
Tech State/Province:
Tech Postal Code:70-419
Tech Country:PL
Tech Phone:+48.914325555
Tech Phone Ext.:
Tech FAX:
Tech FAX Ext.:
Tech Email:dns@home.pl
Name Server:DNS.HOME.PL
Name Server:DNS2.HOME.PL
Name Server:DNS3.HOME.PL

Szczecin is a city in Poland.
Seems to have some nice castles.
http://en.wikipedia.org/wiki/Szczecin

Eric

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

#3222

Andy "Krazy" Glew wrote:
> 
> But I also found another website, waboba.info, that seems to be a clone 
> of comp-arch.net.

Hmmm... did a nslookup on waboba.info and got IP 69.163.174.83
which is the same as semipublic.comp-arch.net

Looked that up and it reports as semipublic.comp-arch.net
located in the California, city BREA.
http://ip-address-lookup-v4.com/lookup.php?ip=69.163.174.83

Eric

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

#3234

On 8/28/2011 8:49 PM, EricP wrote:
> Andy "Krazy" Glew wrote:
>>
>> But I also found another website, waboba.info, that seems to be a
>> clone of comp-arch.net.
>
> Hmmm... did a nslookup on waboba.info and got IP 69.163.174.83
> which is the same as semipublic.comp-arch.net
>
> Looked that up and it reports as semipublic.comp-arch.net
> located in the California, city BREA.
> http://ip-address-lookup-v4.com/lookup.php?ip=69.163.174.83
>
> Eric

Interesting.

I had already done the whois.

But I had not thought to do the nslookup.

(I suppose the times that I could see differences between my site and 
the other site may have just been caching effects.)

Now, why would somebody direct THEIR site to MY comp-arch.net site? 
What's the advantage in that?

The suspicious part of me suspects prepping for something nefarious.

(Of course, it might always be a DNS takeover, resulting in MY site 
being directed to HIS.  ...  No, doesn't seem to be, since that is the 
only site that I pay for a "unique IP" on (Dreamhost doesn't do static 
IPs), and that is what Dreamhost, accessed across HTTPS, reports.  I 
suppose it is possible that they have taken over Dreamhost. )

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

#3238

Andy "Krazy" Glew wrote:
> On 8/28/2011 8:49 PM, EricP wrote:
>> Andy "Krazy" Glew wrote:
>>>
>>> But I also found another website, waboba.info, that seems to be a
>>> clone of comp-arch.net.
>>
>> Hmmm... did a nslookup on waboba.info and got IP 69.163.174.83
>> which is the same as semipublic.comp-arch.net
>>
>> Looked that up and it reports as semipublic.comp-arch.net
>> located in the California, city BREA.
>> http://ip-address-lookup-v4.com/lookup.php?ip=69.163.174.83
>>
>> Eric
> 
> Interesting.
> 
> I had already done the whois.
> 
> But I had not thought to do the nslookup.
> 
> (I suppose the times that I could see differences between my site and 
> the other site may have just been caching effects.)
> 
> Now, why would somebody direct THEIR site to MY comp-arch.net site? 
> What's the advantage in that?
> 
> The suspicious part of me suspects prepping for something nefarious.
> 
> (Of course, it might always be a DNS takeover, resulting in MY site 
> being directed to HIS.  ...  No, doesn't seem to be, since that is the 
> only site that I pay for a "unique IP" on (Dreamhost doesn't do static 
> IPs), and that is what Dreamhost, accessed across HTTPS, reports.  I 
> suppose it is possible that they have taken over Dreamhost. )

I figured someone did a typo entering the IP address for
waboba.info and accidentally pointed their name at your server.
I suppoose an email to biuro@tootu.pl or their host
dns@home.pl would resolve it.

Translating their website http://tootu.pl

A Waboba appears to be toy like a frisbee or something.
"The only ball that bounces off the water"
http://translate.google.ca/translate?js=n&prev=_t&hl=en&ie=UTF-8&layout=2&eotf=1&sl=pl&tl=en&u=tootu.pl&act=url

Their hosting site is:
http://translate.google.ca/translate?js=n&prev=_t&hl=en&ie=UTF-8&layout=2&eotf=1&sl=pl&tl=en&u=home.pl&act=url

Eric

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

#3243

On 8/29/2011 9:40 AM, EricP wrote:
> Andy "Krazy" Glew wrote:
>> On 8/28/2011 8:49 PM, EricP wrote:
>>> Andy "Krazy" Glew wrote:
>>>>
>>>> But I also found another website, waboba.info, that seems to be a
>>>> clone of comp-arch.net.
>>>
>>> Hmmm... did a nslookup on waboba.info and got IP 69.163.174.83
>>> which is the same as semipublic.comp-arch.net
>>>
>>> Looked that up and it reports as semipublic.comp-arch.net
>>> located in the California, city BREA.
>>> http://ip-address-lookup-v4.com/lookup.php?ip=69.163.174.83
>>>
>>> Eric
>>
>> Interesting.
>>
>> I had already done the whois.
>>
>> But I had not thought to do the nslookup.
>>
>> (I suppose the times that I could see differences between my site and
>> the other site may have just been caching effects.)
>>
>> Now, why would somebody direct THEIR site to MY comp-arch.net site?
>> What's the advantage in that?
>>
>> The suspicious part of me suspects prepping for something nefarious.
>>
>> (Of course, it might always be a DNS takeover, resulting in MY site
>> being directed to HIS. ... No, doesn't seem to be, since that is the
>> only site that I pay for a "unique IP" on (Dreamhost doesn't do static
>> IPs), and that is what Dreamhost, accessed across HTTPS, reports. I
>> suppose it is possible that they have taken over Dreamhost. )
>
> I figured someone did a typo entering the IP address for
> waboba.info and accidentally pointed their name at your server.
> I suppoose an email to biuro@tootu.pl or their host
> dns@home.pl would resolve it.
>
> Translating their website http://tootu.pl
>
> A Waboba appears to be toy like a frisbee or something.
> "The only ball that bounces off the water"
> http://translate.google.ca/translate?js=n&prev=_t&hl=en&ie=UTF-8&layout=2&eotf=1&sl=pl&tl=en&u=tootu.pl&act=url
>
>
> Their hosting site is:
> http://translate.google.ca/translate?js=n&prev=_t&hl=en&ie=UTF-8&layout=2&eotf=1&sl=pl&tl=en&u=home.pl&act=url
>
>
> Eric

I was beginning to think that this was innocuous "Never ascribe to 
malice what can be attributed to stupidity/accident".

However, worrying about malice is good - because fixing malice is 
urgent, whereas fixing an accidental error is less urgent.

---

I find it interesting that DNS does not have a mechanism to ensure that 
domains and P addresses are not consistent.   E.g. a digital 
signatute/hash including both, made with a private key corresponding to 
a public key posted in whois.

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

#3244

On 8/29/2011 9:40 AM, EricP wrote:
> Andy "Krazy" Glew wrote:
>> On 8/28/2011 8:49 PM, EricP wrote:
>>> Andy "Krazy" Glew wrote:
>>>>
>>>> But I also found another website, waboba.info, that seems to be a
>>>> clone of comp-arch.net.
>>>
>>> Hmmm... did a nslookup on waboba.info and got IP 69.163.174.83
>>> which is the same as semipublic.comp-arch.net
>>>
>>> Looked that up and it reports as semipublic.comp-arch.net
>>> located in the California, city BREA.
>>> http://ip-address-lookup-v4.com/lookup.php?ip=69.163.174.83
>>>
>>> Eric
>>
>> Interesting.
>>
>> I had already done the whois.
>>
>> But I had not thought to do the nslookup.
>>
>> (I suppose the times that I could see differences between my site and
>> the other site may have just been caching effects.)
>>
>> Now, why would somebody direct THEIR site to MY comp-arch.net site?
>> What's the advantage in that?
>>
>> The suspicious part of me suspects prepping for something nefarious.
>>
>> (Of course, it might always be a DNS takeover, resulting in MY site
>> being directed to HIS. ... No, doesn't seem to be, since that is the
>> only site that I pay for a "unique IP" on (Dreamhost doesn't do static
>> IPs), and that is what Dreamhost, accessed across HTTPS, reports. I
>> suppose it is possible that they have taken over Dreamhost. )
>
> I figured someone did a typo entering the IP address for
> waboba.info and accidentally pointed their name at your server.
> I suppoose an email to biuro@tootu.pl or their host
> dns@home.pl would resolve it.
>
> Translating their website http://tootu.pl
>
> A Waboba appears to be toy like a frisbee or something.
> "The only ball that bounces off the water"
> http://translate.google.ca/translate?js=n&prev=_t&hl=en&ie=UTF-8&layout=2&eotf=1&sl=pl&tl=en&u=tootu.pl&act=url
>
>
> Their hosting site is:
> http://translate.google.ca/translate?js=n&prev=_t&hl=en&ie=UTF-8&layout=2&eotf=1&sl=pl&tl=en&u=home.pl&act=url
>
>
> Eric

I was beginning to think that this was innocuous "Never ascribe to 
malice what can be attributed to stupidity/accident".

However, worrying about malice is good - because fixing malice is 
urgent, whereas fixing an accidental error is less urgent.

---

I find it interesting that DNS does not have a mechanism to ensure that 
domains and IP addresses are consistent.   E.g. a digital signature/hash 
including both, made with a private key corresponding to a public key 
posted in whois.

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

#3255

On Mon, 29 Aug 2011 12:00:58 -0700, "Andy \"Krazy\" Glew"
<andy@SPAM.comp-arch.net> wrote:

>I find it interesting that DNS does not have a mechanism to ensure that 
>domains and IP addresses are consistent.   E.g. a digital signature/hash 
>including both, made with a private key corresponding to a public key 
>posted in whois.

How would that help?  The information still would have to be correct
the first time to create the hash.  Only afterward could the hash
check the validity.

George

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

#3256

"Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> writes:
> I find it interesting that DNS does not have a mechanism to ensure
> that domains and IP addresses are consistent.   E.g. a digital
> signature/hash including both, made with a private key corresponding
> to a public key posted in whois.

one of the domain name infrastrucutre vulnerabilities is domain name
hijacking,

part of DNSSEC was registering a public key at the some time the domain
name registration was done. then all future communication between the
domain name owner and the domain name infrastructure is digially signed
with the own-file pubic key ... several instances of domain name
hijacking where impersonator fraudulent convinces the domain name
infrastructure to update the domain name inframation.

Then the fraudulent domain name owner can apply to the SSL domain name
issuer for a valid SSL digital certification ... providing valid
information that corresponds with the information on file at the domain
name infrastructure.

To some extent the SSL domain name vendors were supporting such DNSSEC
operation with pre-registered, onfile public key. Part of the issue is
that they currently use an error-prone, expensive, and time-consuming
identification process that attempts to match the information supplied
on the SSL domain name digital certificate application with the
information on-file at the domain name infrastructure.

With on-file, registered public keys at the domain name infrastructure,
the SSL domain name infrastructure can start reguiring that SSL domain
name certificate application be digitally signed. Then the SSL digital
certificate vendor can retrieve the on-file public key from the domain
name infrastructure to verify the signature on the SSL domain name
certificate application. note that this creates something of catch-22
for the SSL digital certificate vendors since if they could do real-time
retrieval of on-file public keys from the domain name infrastructure,
then could the rest of the world (obsoleting need for SSL digital
certificates for distribution of public keys) ... misc. past posts
http://www.garlic.com/~lynn/subpubkey.html#catch22

I've suggested a much more efficient and revised SSL handshake where
onfile public key could be piggy-backed in standard DNS response ... and
then used to encrypt the generated session secret key which is sent
during initial connection.

for other drift ... from today, fraudulent digital certificate:

Fraudulent Google credential found in the wild
http://www.theregister.co.uk/2011/08/29/fraudulent_google_ssl_certificate/
Hackers acquire Google certificate, could hijack Gmail accounts
http://www.computerworld.com/s/article/9219569/Hackers_acquire_Google_certificate_could_hijack_Gmail_accounts

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

#3266

Anne & Lynn Wheeler <lynn@garlic.com> writes:
> for other drift ... from today, fraudulent digital certificate:
>
> Fraudulent Google credential found in the wild
> http://www.theregister.co.uk/2011/08/29/fraudulent_google_ssl_certificate/
> Hackers acquire Google certificate, could hijack Gmail accounts
> http://www.computerworld.com/s/article/9219569/Hackers_acquire_Google_certificate_could_hijack_Gmail_accounts

re:
http://www.garlic.com/~lynn/2011k.html#63 Somewhat off-topic: comp-arch.net cloned, possibly hacked

supercomputer & SSL trivia ... from:
http://www.garlic.com/~lynn/2011k.html#50 The real reason IBM didn't want to dump more money into Blue Waters

in this referenced cluster scaleup jan92 meeting in ellison's conference
room
http://www.garlic.com/~lynn/95.html#13

two of the (other) people (mentioned in the meeting) later leave and
join a small client/server startup responsible for something called
commerce server. As mentioned in the above (supercomputer reference)
... we also leave ... later we are brought in to consult at the small
client/server startup because they want to do payment transactions on
the server; the small client/server startup had invented this technology
called "SSL" they want to use ... the result is now frequently called
"electronic commerce". Not long afterwards, I coin the term "comfort
certificates" to differentiate between (comfort from the) appearance of
security and real security. misc.  past posts about ssl digital
certificates http://www.garlic.com/~lynn/subpubkey.html#sslcerts

other RDBMS trivia ... one of the other people in the Jan92 meeting
would claim that they handled most of the (RDBMS) technology transfer
from Endicott (SQL/DS) back to STL for DB2. Previously I had done some
amount of the System/R tech transfer from SJR to Endicott for SQL/DS.
misc. past posts mentioning system/r
http://www.garlic.com/~lynn/submain.html#systemr

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

#3275

Anne & Lynn Wheeler <lynn@garlic.com> writes:
> name registration was done. then all future communication between the
> domain name owner and the domain name infrastructure is digially signed
> with the own-file pubic key ... several instances of domain name
> hijacking where impersonator fraudulent convinces the domain name
> infrastructure to update the domain name inframation.

re:
http://www.garlic.com/~lynn/2011k.html#63 Somewhat off-topic: comp-arch.net cloned, possibly hacked

misc finger slips ... "digitally signed *and verified* with the on-file
publickey"

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

#3263

Andy "Krazy" Glew wrote:
>
> I find it interesting that DNS does not have a mechanism to ensure that
> domains and IP addresses are consistent. E.g. a digital signature/hash
> including both, made with a private key corresponding to a public key
> posted in whois.

Sounds like a good idea, I wonder what I'd get from googling "secure dns"?
...

http://www.dnssec.net/ is the second hit.

:-)

Terje
-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

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

#3267

On 8/30/2011 4:53 AM, Terje Mathisen wrote:
> Andy "Krazy" Glew wrote:
>>
>> I find it interesting that DNS does not have a mechanism to ensure that
>> domains and IP addresses are consistent. E.g. a digital signature/hash
>> including both, made with a private key corresponding to a public key
>> posted in whois.
>
> Sounds like a good idea, I wonder what I'd get from googling "secure dns"?
> ....
>
> http://www.dnssec.net/ is the second hit.
>
> :-)
>
> Terje

OK, I'm stupid.

So my next questions are:

1) why wasn't security designed in from the start?

2) why isn't this everywhere?

Oh, yeah, the answer is probably "The original designers of the Internet 
didn't pay attention to security".

Which is part of the reason why I stopped paying attention to network 
protocols years ago - in frustration because of thtche lousy security.

(The first US company worked at, The Little Software House on the 
Prairie, (a) was where I learned a lot about hardware and OS, (b) had 
been the Illiac networking group, (c) was a pioneer in secure OSes and 
secure networking.   They made part of the living adding security as an 
afterthought to networking.   It always annoyed me that security had not 
been designed in from scratch.)

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

#3271

"Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> writes:
> OK, I'm stupid.
>
> So my next questions are:
>
> 1) why wasn't security designed in from the start?
>
> 2) why isn't this everywhere?
>
> Oh, yeah, the answer is probably "The original designers of the
> Internet didn't pay attention to security".
>
> Which is part of the reason why I stopped paying attention to network
> protocols years ago - in frustration because of thtche lousy security.
>
> (The first US company worked at, The Little Software House on the
> Prairie, (a) was where I learned a lot about hardware and OS, (b) had
> been the Illiac networking group, (c) was a pioneer in secure OSes and
> secure networking.   They made part of the living adding security as
> an afterthought to networking.   It always annoyed me that security
> had not been designed in from scratch.)

re:
http://www.garlic.com/~lynn/2011k.html#63 Somewhat off-topic: comp-arch.net cloned, possibly hacked
http://www.garlic.com/~lynn/2011k.html#65 Somewhat off-topic: comp-arch.net cloned, possibly hacked

other trivia ... the person that originally created DNS in the early
80s, had done work at the science center a decade earlier
http://www.garlic.com/~lynn/subtopic.html#545tech

most of the internet was done with little or no thought about attacks
and countermeasures ... or sevice level quality. I've made numerous
references to work on "electronic commerce" ... that it took nearly ten
times the original effort ... to take well designed, well coded, and
well tested code and turn it into "service" quality ... being able to
handle large category of failures, including those resulting from
attacks (in general I've found it takes 4-10 times the effort to take
well crafted "application" code and make it "service" quality).
Part of the issue was that I had final sign-off on the implementation
between the webserver and something called the "payment gateway"
(sat between the internet and payment networks) ... some past posts
http://www.garlic.com/~lynn/subnetwork.html#gateway

but didn't have similar authority regarding the client/server side (even
relative trivial stuff was claimed to be "too complicated")

another problem was the whole issue of any sort of encryption technology
during most of the period (both patent and heavy licensing barrier as
well as gov. opposition) ... in the 80s, I was so vociferous on the
subject, that some guy from 3-letter gov agency dropped by my office to
discuss my concerns.

I've frequently mention that the internal network was larger than
the arpanet/internet from just about the beginning until possibly
late '85 or early '86 ... and the company required link encryptors
on all links
http://www.garlic.com/~lynn/subnetwork.html#internalnet

There was claim that in the mid-80s, the internal network had half of
all the link encryptors in the world. Even tho these were
commerical-off-the-shelf hardware, there was frequently still gov.
opposition when links crossed national boundaries. It is in this period,
that i claim I learned that there was three kinds of encryption: 1) the
kind they don't care about, 2) the kind you can't do, and 3) the kind
you can only do for them.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

#3297

In article <m3bov7ugem.fsf@garlic.com>, lynn@garlic.com (Anne & Lynn 
Wheeler) wrote:

> most of the internet was done with little or no thought about attacks
> and countermeasures ... or sevice level quality.

 While bowing to your experience I though that the internet originated 
in ARPA net. As that was a closed system concern was with physical 
attacks not software attacks and that attitude seems to have carried over.
 
 Security could be handled by the various file servers used for ftp and  
later usenet. The WWW originated as an application at Cern and nobody 
seems to have paid much attention to the fact that when it spread beyond 
Cern there were no built in security features. 

 Ken Young

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

#3300

kenney@cix.compulink.co.uk writes:
>  While bowing to your experience I though that the internet originated 
> in ARPA net. As that was a closed system concern was with physical 
> attacks not software attacks and that attitude seems to have carried over.
>  
>  Security could be handled by the various file servers used for ftp and  
> later usenet. The WWW originated as an application at Cern and nobody 
> seems to have paid much attention to the fact that when it spread beyond 
> Cern there were no built in security features. 

however, the big switch-over was on 1jan1983 from closed system with
IMPs to "internetworking" protocol ... that was specifically designed to
internet lots of different networks ... which was implicitly open
(although lots of people may have continued to think locally and were
unprepared for wildwest anarchy of open environment).

In the early 80s, there was OSI ... and the government in the late 80s
attempted to eliminate internet, mandating GOSIP.

We ran afaul of OSI attempting to take HSP to ANSI x3s3.3 (ISO charted
standards body for network/transport level related standards). However
at the time, ISO has mandate that protocols that violated OSI model
couldn't be approved. HSP included internetworking support ... which
didn't exist in OSI ... and HSP was rejected (it had a couple other
features which also didn't conform to OSI). misc. past posts mentioning
HSP
http://www.garlic.comp/~lynn/subnetwork.html#xtphsp

for other topic drif ... HTML morphing from SGML
http://infomesh.net/html/history/early

GML had been invented at the science center in 1969
http://www.garlic.com/~lynn/submain.html#sgml

and morphed into SGML a decade later ... before morphing into HTML after
another decade. As previously mentioned, person originally responsible
for DNS in the early 80s, worked at the science center a decade earlier
... misc. past posts mentioning science center
http://www.garlic.com/~lynn/subtopic.html#545tech

The first webserver outside europe/cern was at SLAC (sister institution
to CERN) on their virtual-machine based (vm370) system (also originated
at the science center):
http://www.slac.stanford.edu/history/earlyweb/history.shtml

the technology basis for modern internet was tcp/ip, the operational
basis for modern internet was the nsfnet backbone, and the business
basis for modern internet was cix.

misc. past email working with director of NSF on what was to become
NSFNET backbone
http://www.garlic.com/~lynn/lhwemail.html#nsfnet

when the NSFNET backone RFP was released ... internal politics prevented
us from bidding. Director of NSF attempted to help by writting a letter
to the company (with support of various other agency heads), copying the
CEO ... with references to what we already had running was at least five
years ahead of all RFP responses. That just made the internal politics
worse. As an aside, some of the same executives involved in blocking
being able to bid on NSFNET ... also were later involved in transferring
cluster scaleup ... mentioned in this recent comp.arch post:
http://www.garlic.com/~lynn/2011k.html#50 The real reason IBM didn't want to dump more money into Blue Waters

past posts in this thread:
http://www.garlic.com/~lynn/2011k.html#63 Somewhat off-topic: comp-arch.net cloned, possibly hacked
http://www.garlic.com/~lynn/2011k.html#65 Somewhat off-topic: comp-arch.net cloned, possibly hacked
http://www.garlic.com/~lynn/2011k.html#67 Somewhat off-topic: comp-arch.net cloned, possibly hacked
http://www.garlic.com/~lynn/2011k.html#74 Somewhat off-topic: comp-arch.net cloned, possibly hacked

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

#3309

In article <Ra2dndAQJc7KrMPTnZ2dnUVZ8mydnZ2d@giganews.com>,
 <kenney@cix.compulink.co.uk> wrote:
>In article <m3bov7ugem.fsf@garlic.com>, lynn@garlic.com (Anne & Lynn 
>Wheeler) wrote:
>
>> most of the internet was done with little or no thought about attacks
>> and countermeasures ... or sevice level quality.
>
> While bowing to your experience I though that the internet originated 
>in ARPA net. As that was a closed system concern was with physical 
>attacks not software attacks and that attitude seems to have carried over.

It's not that simple, but you are fairly close.


Regards,
Nick Maclaren.

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

#3272

In article <4E5CECCB.2090404@SPAM.comp-arch.net>,
Andy \"Krazy\" Glew <andy@SPAM.comp-arch.net> wrote:
>
>Which is part of the reason why I stopped paying attention to network 
>protocols years ago - in frustration because of thtche lousy security.

As any pure mathematician will tell you, debating the properties
of empty sets is invalid, and the original Internet security
characteristics is definitely a null set :-)


Regards,
Nick Maclaren.

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

#3295

Andy "Krazy" Glew wrote:
> 1) why wasn't security designed in from the start?

You've answered this one yourself: The starting point was "keep 
everything absolutely open".
>
> 2) why isn't this everywhere?

The real question is this:

Given Secure DNS, there is absolutely no real reason for having a a 
totally separate mechanism, with 200+ CAs all getting a _lot_ of money 
for issuing SSL certificates:

Each and every DNS domain name registered with a Secure DNS certificate 
could/should also be _the_ CA for all servers in that domain.

The main problem with this approach is probably that it would remove a 
huge source of income for the CAs: Back in 2009 Netcraft reported that 
the number of such certificates passed 1 million.

They also reported that over 60% of all reachable (public) https/ssl 
servers used private/self-signed certs, so the need to shortcut the CAs 
is obviously there.

Terje
-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

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

#3299

Terje Mathisen <"terje.mathisen at tmsw.no"> writes:
> The real question is this:
>
> Given Secure DNS, there is absolutely no real reason for having a a
> totally separate mechanism, with 200+ CAs all getting a _lot_ of money
> for issuing SSL certificates:
>
> Each and every DNS domain name registered with a Secure DNS
> certificate could/should also be _the_ CA for all servers in that
> domain.
>
> The main problem with this approach is probably that it would remove a
> huge source of income for the CAs: Back in 2009 Netcraft reported that
> the number of such certificates passed 1 million.

re:
http://www.garlic.com/~lynn/2011k.html#63 Somewhat off-topic: comp-arch.net cloned, possibly hacked
http://www.garlic.com/~lynn/2011k.html#65 Somewhat off-topic: comp-arch.net cloned, possibly hacked
http://www.garlic.com/~lynn/2011k.html#67 Somewhat off-topic: comp-arch.net cloned, possibly hacked

Domain name CA industry is somewhat caught in catch-22, they need part
of DNSSEC where domain name owner registers public key as countermeasure
to domain name hijacking (and all future communication is authenticated
with the on-file public key) ... since critical part of their business
is matching information on certificate application with the information
on file at domain name infrastructure (as regard true domain name
owner). But once those keys are on-file and online available ... they
can be used in lieu of digital certificates
http://www.garlic.com/~lynn/subpubkey.html#catch22

the certification authority business tries to imply digital certificates
have some sort of mystical properties. their original design point was
electronic version of letters of credit/introduction (from the sailing
ship & earlier periods where relying parties would have no other
alternatives regarding first time interaction with complete stranger)
for the offline email of the early 80s (dial-up local postoffice,
exchange email, hangup, and have first-time email from complete stranger
that needs some sort of authentication).

for higher-value interactions, relying party has either local
information and/or access to online authority to obtain the information
(especially with ubiquitous internet connectivity).

typical non-CA operation, is relying party has trusted local store where
they retrieve on-file public key for authenticating digitally signed
information. 

for typical CA operation, relying party has trusted local store of CA
public keys (purely artifect side-effect stored in certificate format)
that is retrieved to verify the digital signature on an appended digital
certificate, then the public key is extracted from the appended digital
certificate to verify the digital signature on the actual message.

the root trust authority for relying parties is trusted local store of
public keys (wither it is the non-CA model or the CA model). In the DNS
case, each user has list of root domain name servers ip-addresses in
local store of trusted domain name servers. This local trusted store of
root domain name server ip-addresses is straight-forward extended to
have public keys in combination with the corresponding ip-addresses
(which would be required regardless of whether a non-CA or CA model was
used). lots of past posts of certificate-less public key discussions
http://www.garlic.com/~lynn/subpubkey.html#certless

in the mid-90s, the major certification authorities were circulating
busines plans on wallstreet that every person in the country would have
an annually renewed digital certificate @$100/annum (minimum $20B/annum
industry revenue). The claim was that it would be justified by the
financial industry requiring a certificate appended to every financial
transaction. The problem was that even abbreviated digital certificates
had payload size that was 100 times larger than existing payment
transaction payload ... and the processing MIPs for digital certificate
was 100 times larger than existing payment transaction processing ...
which was redundant and superfluous.

The design point for digital certificates was first time interaction
between complete stranger. Since consumers already had to have a
business relationship with their financial institution (that would be
processing the financial transaction) ... that having a 100 times
payload and processing bloat was redundant and superfluous ... all the
financial institution needed was to have their customer register a
public key as part of their account information.

In fact, for other reasons, the financial institutions (before realizing
the enormous bloat overhead) had already required that transactions have
appended digital certificates that were "relying-party only"
... i.e. specific to institution ... that included the customers account
number. There was just an artificial distinction that the bank customer
registered their account number and public key with a different
operation than opened the account. Showing that collapsing both the
account number and public key registration into single business
operation ... make it clear that appending digital certificates (on
every payment transaction) was redundant and superfluous (as well as
eliminated the 100* time payload and processing bloat) ... which shot
the $20B/annum industry business case.  some past posts discussing the
enormous bloat 
http://www.garlic.com/~lynn/subpubkey.html#bloat

The certification authority interests attempted to come back in
financial standards body with work item for "compressed"
relying-party-only digital certificates ... where information was
eliminated that was either 1) already in possession of the financial
institution or 2) was common to all relying-party-only digital
certificates. This was anticipated to possibly getting the payload bloat
down to only ten times existing payload transaction size. Instead of
showing that appended digital certificates were redundant and
superfluous, I showed that such digital certificates could be compressed
to zero bytes ... and that there could be mandatory append of zero byte
digital certificates on every financial transaction.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.arch

csiph-web