| 01:31.06 | *** join/#maemo infobot (ibot@208.53.50.136) |
| 01:31.06 | *** topic/#maemo is Welcome to #maemo http://maemo.org/intro/ | N9/harmattan related questions please in #harmattan ! | "firmware" see ~lf (or ~tabletsdev ~combined ~emmc ~flasher) sdk: ~sb | http://wiki.maemo.org/Community_Council | Source: http://wiki.maemo.org/Sources | Chanlog: http://mg.pov.lt/maemo-irclog | #maemo-ssu is where the (few) devels and maintainers of the maemo-future meet |
| 01:31.07 | *** mode/#maemo [+v infobot] by ChanServ |
| 02:21.53 | *** join/#maemo tm (~sinnlos@unaffiliated/tm) |
| 02:22.17 | *** join/#maemo luke-jr (~luke-jr@unaffiliated/luke-jr) |
| 03:56.55 | *** join/#maemo pagurus (~user@i59F7C47F.versanet.de) |
| 04:05.46 | *** join/#maemo LauRoman (~LauRoman@5-14-13-12.residential.rdsnet.ro) |
| 04:33.51 | *** join/#maemo povbot (~supybot@office.pov.lt) |
| 05:36.13 | *** join/#maemo spiiroin (~spiiroin@2001:998:2a:deaf:fd66:53d0:a9d6:dca8) |
| 05:39.50 | totalizator | why not? |
| 06:14.35 | *** join/#maemo mavhc (~mavhc@cpc77319-basf12-2-0-cust433.12-3.cable.virginm.net) |
| 06:29.24 | brolin_empey | totalizator: No reason not to in my experience and opinion but DocScrutinizer05 has his reasons to buy a certificate instead of using LE. Personally I like LE because it allows me to automate the process of renewing the certificate. That is actually a large part of the reason I switched to LE. The reason for using a computer in the first place is to work more efficiently by having the computer do tedious, repetitive work to save valuable human time for |
| 06:29.24 | brolin_empey | things the computer cannot do itself, such as programming the computer. I do not want to risk interruption of service because I have to manually renew certificates if this renewal process can be automated. |
| 06:32.19 | *** join/#maemo hurrian (~hurrian@unaffiliated/rikanee) |
| 06:33.43 | brolin_empey | In this case, though, I found it remarkable that BMW uses LE because BMW is a large company with broad brand recognition by the general public, not only by engineers. In my experience, it seems that large companies usually still buy a conventional certificate instead of using LE, at least for their Web sites that I access as a basically English-language monoglot whose travels IRL are limited to Canada, USA including Hawaii and Alaska, and Mexico. |
| 06:36.14 | brolin_empey | But hey, I can speak x86 assembly language and machine code. :-P |
| 06:38.08 | *** join/#maemo dafox (~dafox@188.206.73.63) |
| 06:39.08 | brolin_empey | It took me around three decades of living in Canada, not Quebec though, to realise that âbonjourâ literally means âgood dayâ instead of âhelloâ. I thought it meant âhelloâ because âhelloâ is usually translated to French as âbonjourâ in my experience. |
| 06:45.14 | brolin_empey | Do new road vehicles sold in continental Europe have miles on the speedometer? It surprises me that some automakers, at least Volkswagen and Audi, no longer include miles on the speedometer of vehicles sold in Canada even though most Canadians live close to the USA, where road signs still use miles instead of metric, same as the UK. |
| 06:50.40 | brolin_empey | I realised that if the Tesla brand was used for a diesel vehicle then the vehicle may have a âTesla coilâ indicator light. :-D |
| 06:55.27 | brolin_empey | Does anyone from Taiwan say âflag of Taiwanâ instead of âflag of the Republic of Chinaâ? |
| 06:57.46 | brolin_empey | Strictly speaking, there is, as far as I can tell, no flag of Taiwan, only the flag of the Republic of China, which is effectively a flag of Taiwan. |
| 06:59.20 | brolin_empey | I mean the current flag of the ROC, not the previous flag of the ROC. |
| 07:01.12 | brolin_empey | Serious question that I thought of: What do a Commodore 64 or Commodore 128 and a car with an automatic transmission with a horizontally-moving gear selector lever have in common? |
| 07:02.52 | Vajb | harware restrictions ;) |
| 07:03.59 | brolin_empey | Or a typewriter, which is why the early Commodore computers have the thing that is the answer. |
| 07:05.47 | brolin_empey | The answer is (a) shift lock as opposed to a caps lock. |
| 07:07.10 | brolin_empey | I do not know if a vehicle with an automatic transmission with a column shifter has a shift lock because I have possibly literally zero experience driving such a vehicle. |
| 07:08.41 | brolin_empey | I have more experience with 5.25-inch flexible disc drives than with automatic transmissions. |
| 07:11.52 | brolin_empey | Vajb: Seriously, though, does any Commodore computer truly have hardware restrictions, other than the write prevent mechanism of the flexible disc drive? I thought that Commodore usually did not try to restrict the user of their products. |
| 07:18.07 | brolin_empey | It also occurred to me recently that the automotive industry may have originally had only one manual that covered both using and servicing a vehicle before splitting the service manual from the user manual? |
| 07:24.37 | brolin_empey | DocScrutinizer05: What does âDocScrutinizerâ mean? Document(ation) Scrutinizer? Doctor Scrutinizer? |
| 07:35.51 | *** join/#maemo Venemo (~venemo@fedora/Venemo) |
| 08:10.48 | *** join/#maemo eMHa (~mh@217.5.215.150) |
| 08:30.16 | Juesto | brolin_empey: doctor is most likely, perhaps look it up? |
| 08:30.50 | Juesto | pfft |
| 08:31.01 | Juesto | thats a silly comparsion |
| 08:42.01 | *** join/#maemo jskarvad (jskarvad@redhat/jskarvad) |
| 09:00.49 | sixwheeledbeast | I assumed Doctor. the issue with certificates is it's a massive chain of trust and if that is compromised somehow it leads to false security. Cert companies have gone bust by blindly or systematically adding certs you loose that web of trust and no one will trust you. |
| 09:08.24 | Maxdamantus | Do big companies use conventional certificates because they're better, or because that's just what companies have always done? |
| 09:10.47 | Maxdamantus | You can probably find a bunch of other technologies that are pretty much only used by big companies, mostly because it's big companies that have been around long enough to still be using them. |
| 09:10.57 | Maxdamantus | things like Java application servers come to mind. |
| 09:11.39 | Juesto | Maxdamantus: companies use standard certificates because its whats trusted and what browsers have built in, they use their own within the trusted well known root certificate that is on the OSes |
| 09:11.51 | sixwheeledbeast | I would imagine larger companies would be happy to pay for a better known more trusted company. Also they maybe happy with the relationship they have built up with the company. |
| 09:12.24 | Maxdamantus | Juesto: browsers obviously support LE though, otherwise LE wouldn't be very useful. |
| 09:12.30 | sixwheeledbeast | It possible BMW have got new people in to work on there web stack. |
| 09:12.35 | Juesto | ? |
| 09:13.00 | Maxdamantus | Juesto: âits whats trusted and what browsers have built inâ |
| 09:13.13 | Juesto | LE? |
| 09:13.15 | Maxdamantus | Juesto: LE is trusted in the same way as other CAs. |
| 09:13.19 | Maxdamantus | Juesto: letsencrypt. |
| 09:13.30 | Juesto | oh right |
| 09:13.48 | Juesto | yeah, LE is pretty recent as far i gather |
| 09:14.20 | Juesto | but that one likely uses another well known root cert |
| 09:14.49 | Juesto | apologies for the little confusion i had |
| 09:14.58 | Maxdamantus | I was under the impression that LE has their own root cert(s), but I haven't looked into it. |
| 09:15.25 | Juesto | go ahead and confirm? |
| 09:16.49 | Maxdamantus | "DST Root CA X3"? |
| 09:18.02 | Maxdamantus | Ah okay, that's a certificate from some "IdenTrust" . |
| 09:18.41 | Juesto | :) |
| 09:20.57 | Maxdamantus | But that's obviously quite a lot of trust that "IdenTrust" must be putting in LE. |
| 09:22.41 | sixwheeledbeast | Exactly... |
| 09:22.48 | Maxdamantus | isn't particularly familiar with certificates, but presumably they've signed LE's certificate saying they can sign for any domain. |
| 09:23.16 | Maxdamantus | So IdenTrust and LE are effectively the same thing here. |
| 09:23.43 | Maxdamantus | "I trust you to have as much power as I have" |
| 09:27.04 | sixwheeledbeast | With all encryption like this you have some public key and private key. The cert co's job is as a third party to verify those keys are correct and valid. |
| 09:28.31 | Maxdamantus | Well, its job is to vouch for the association of some public key with some domain name. |
| 09:29.12 | Maxdamantus | I understand how it works in principle, just don't know the details around validation processes, the actual trust delegation, etc |
| 09:30.11 | Maxdamantus | I can't see something explicitly like "domain: *" in the information about the LE certificate through Firefox's certificate viewer, so presumably the delegation is in the form of something like "Signer" |
| 09:32.30 | Maxdamantus | I'm guessing it's the "Is a Certificate Authority" part under "Extensions > Certificate Basic Constraints" |
| 09:33.09 | Maxdamantus | so if a valid certificate says "Is a Certificate Authority", then any certificate signed by that certificate is also valid. |
| 09:34.56 | Maxdamantus | But surely there must be other ways to delegate these things, eg, if you have a valid certificate for "*.google.com", presumably you can sign another certificate for "mail.google.com", without being a CA. |
| 09:37.29 | *** join/#maemo florian (~florian_k@Maemo/community/contributor/florian) |
| 09:42.06 | Maxdamantus | Google has at least one of these CA certificates too. |
| 09:42.37 | Maxdamantus | issued by GlobalSign |
| 09:45.16 | sixwheeledbeast | Google have Google Trust Services |
| 09:51.11 | sixwheeledbeast | Superfish... |
| 09:51.17 | sixwheeledbeast | shudders |
| 10:05.41 | *** join/#maemo Kabouik (~kabouik@236.34.200.37.customer.cdi.no) |
| 10:06.11 | *** join/#maemo jskarvad (jskarvad@redhat/jskarvad) |
| 10:14.42 | Vajb | hmm I wonder, if company x trusts company y and company y trusts company x. Who is to say that x and y are trustworthy? |
| 10:15.17 | Vajb | question raised while reading a backlog |
| 10:16.16 | Maxdamantus | Vajb: the trust statements are backwards relative to how certificates normally work. |
| 10:17.43 | Maxdamantus | It should be "y is trusted by x" and "x is trusted by y", since that's what's in the certificates ("y is trusted by x" -> "y includes a signature produced by x") |
| 10:18.27 | KotCzarny | i think vajb wants to know who is at the top of trust |
| 10:19.06 | Vajb | hmm ok, Im still not quite there yet or maybe what KotCzarny said... |
| 10:19.35 | Maxdamantus | but what's imporant is whether you can follow the "_ is trusted by _" relations to a certificate that you're willing to inherently trust, which will happen in this case if either certificate exists in the browser's/OS' certificate store. |
| 10:20.41 | Maxdamantus | afaik, being a "root" is not really important. |
| 10:21.36 | Vajb | I thought more of as is there company z who says x and y are trustworthy |
| 10:21.55 | KotCzarny | no? someone decides who can get in and when and at what conditions |
| 10:22.10 | Vajb | but is this more related to blockchain? |
| 10:22.18 | KotCzarny | and i suppose those in lower roots have to agree to some root conditions |
| 10:22.30 | Maxdamantus | unless "root" means "exists in the browser's/OS' certificate store" |
| 10:22.30 | Maxdamantus | as opposed to being issued by itself. |
| 10:23.03 | KotCzarny | certificate stores usually use whatever is popular/"trusted" |
| 10:26.24 | Vajb | so browser creator gets to decide what certificates his browser has by default? |
| 10:26.31 | KotCzarny | yes |
| 10:26.38 | KotCzarny | unless they use system's one |
| 10:26.49 | Vajb | or maybe develober instead of creator... |
| 10:26.58 | Vajb | developer* |
| 10:27.00 | KotCzarny | but since browser's had to be consistent, they bundle certs themselves |
| 10:27.25 | Vajb | ah os has its own certificates too? |
| 10:27.27 | KotCzarny | some specific builds might use system's one |
| 10:27.36 | KotCzarny | yeah |
| 10:27.45 | Vajb | hmm |
| 10:27.49 | KotCzarny | in debianish world they usually come as ca-certificates package |
| 10:28.05 | KotCzarny | but curl packs it's own often |
| 10:28.39 | Vajb | if some rogue developer puts some dubious certificates in his store would it be possible to them to spread and compromise whole chain of trust? |
| 10:28.40 | KotCzarny | so basically it's a mess, which wouldnt be a mess in updated and supported distro |
| 10:28.44 | KotCzarny | yup |
| 10:29.09 | KotCzarny | but it would only be used by a that particular app |
| 10:29.32 | KotCzarny | unless it goes rogue and modifies system |
| 10:29.34 | Vajb | and that _could_ be possible with, say LE? |
| 10:29.45 | KotCzarny | nah, LE is different story |
| 10:30.19 | Vajb | ok, Im trying to wrap my head around why it is starbge that BMW uses LE. |
| 10:30.26 | Vajb | strange* |
| 10:30.28 | Juesto | eh, its a standard-ish thing |
| 10:30.34 | KotCzarny | because LE is new kid on the block |
| 10:30.50 | Juesto | root certificates are like the root domains, they're on top of the chain |
| 10:30.59 | KotCzarny | and we have yet to see how well they manage things |
| 10:31.45 | Juesto | if LE was a root cert on its own it would have been perhaps a little more exposed/scandalous/newsworthy |
| 10:32.15 | Vajb | ah so it trust exp runs quite low still and it needs few level ups ;) |
| 10:33.02 | Juesto | its more a service |
| 10:33.27 | Vajb | I see. |
| 10:33.44 | Juesto | apparently |
| 10:33.49 | Juesto | dont quote me |
| 10:34.03 | Juesto | neither rely |
| 10:34.08 | KotCzarny | also, their value gets undermined by a 'free cert for everyone' idea |
| 10:34.21 | KotCzarny | which basically includes malware |
| 10:34.28 | Juesto | pfft |
| 10:34.29 | *** join/#maemo florian (~florian_k@Maemo/community/contributor/florian) |
| 10:34.34 | Juesto | what a scam(?) |
| 10:34.40 | KotCzarny | user might see 'oh it's a trusted site' without checking who is the owner of the cert |
| 10:37.55 | Vajb | so should we always check who issued the cert? And even block some certs if they seem dubious? |
| 10:38.06 | KotCzarny | no, who owns the cert |
| 10:38.12 | KotCzarny | issuers are trusted |
| 10:38.18 | Vajb | I think I never checked any certs |
| 10:38.25 | Juesto | issuer != owner |
| 10:38.31 | KotCzarny | but they might sell/issue cert to dubious entity |
| 10:38.40 | Vajb | ah missed that part |
| 10:39.34 | Vajb | actually I recall firefox complaining about certs being old in some page |
| 10:39.53 | Vajb | (I know this is not related to this) |
| 10:40.02 | Vajb | hmm that |
| 10:40.26 | Juesto | must have been your clock or your store being outdated |
| 10:41.13 | KotCzarny | or old browser without updated certs |
| 10:41.16 | Vajb | or I was in some shady back alley of internet |
| 10:41.29 | KotCzarny | might be that too |
| 10:41.54 | Juesto | lel |
| 10:42.03 | Juesto | oh ya you reminded me |
| 10:42.07 | Vajb | I backed off, if you wonder ;) |
| 10:42.16 | Juesto | yes some internet connection can cause issues with certs |
| 10:42.19 | Juesto | and browser warnings |
| 10:42.30 | Juesto | especially flaky ones |
| 10:42.55 | Vajb | hmm can't recall if it was home or with some "free" wlan |
| 10:43.33 | Juesto | there you go |
| 10:43.40 | Juesto | wifi can be terrible |
| 10:45.00 | Vajb | yup. That's why I don't use anything sensitive anymore while on free wifi |
| 10:45.23 | Vajb | like on holidays |
| 10:45.51 | *** join/#maemo spiiroin (~spiiroin@213-216-236-184.bb.dnainternet.fi) |
| 10:47.26 | Juesto | :) |
| 10:50.52 | Maxdamantus | 23:28:39 < Vajb> if some rogue developer puts some dubious certificates in his store would it be possible to them to spread and compromise whole chain of trust? |
| 10:51.06 | Maxdamantus | In his own store? Then he's just compromising whatever software uses that store. |
| 10:51.26 | Maxdamantus | The trust store isn't going to magically replicate to other machines. |
| 10:52.01 | Maxdamantus | The rogue developer would need to do something like change what certificates are distributed as part of something like a Firefox package, or curl or ca-certificates. |
| 10:53.04 | Maxdamantus | (by "a Firefox package", I mean the package used for something like Debian) |
| 10:55.51 | Maxdamantus | But ultimately, the "top" of the trust chain is the stuff running on your system. |
| 10:57.03 | Maxdamantus | Since it's your browser that decides to look in certain places on the filesystem for certificates, and it's your harddrive that decides to return the blocks in the filesystem that happen to be stored certificates, and it's your CPU that decides to execute the browser's code in the correct way. |
| 10:58.41 | KotCzarny | top, but still uses trust from the internet |
| 10:58.50 | KotCzarny | so not the toppish top |
| 10:59.13 | Maxdamantus | But you can say that about any CA, not just the "root" ones. |
| 10:59.18 | KotCzarny | yup |
| 10:59.53 | Maxdamantus | and since LE has a valid CA certificate, they're already fully trusted through these chains. |
| 11:00.26 | Maxdamantus | whether that trust comes from certificates stored directly in Firefox/ca-certificates, or from another such certificate signing LE's one. |
| 11:04.31 | Maxdamantus | actually, LE is already such a certificate on my system. |
| 11:06.13 | Maxdamantus | so it's trusted by both my browser directly, and by DST (which my browser trusts directly) |
| 11:24.48 | *** join/#maemo florian (~florian_k@Maemo/community/contributor/florian) |
| 11:57.03 | *** join/#maemo Venemo (~venemo@fedora/Venemo) |
| 12:49.50 | sixwheeledbeast | An issue is something like superfish, someone gets a fake cert into peoples cert store either through browser or bundled by manufacturer. In this example it was a fake Google cert so you think TLS is working. Malware can then MITM your data on your machine, potentially leaving you with your private and public keys written to your drive in plaintext, that's bad. |
| 12:51.09 | sixwheeledbeast | Older companies are more trusted and therefore further up the web of trust. |
| 12:51.23 | sixwheeledbeast | s/Older/Established |
| 13:47.00 | *** join/#maemo Venemo (~venemo@fedora/Venemo) |
| 14:04.07 | *** join/#maemo Natch (~Natch@h-112-130.A444.priv.bahnhof.se) |
| 14:25.09 | *** join/#maemo eMHa (~mh@217.5.215.150) |
| 14:38.44 | *** join/#maemo florian (~florian_k@Maemo/community/contributor/florian) |
| 15:15.57 | *** join/#maemo Pali (~pali@Maemo/community/contributor/Pali) |
| 16:25.33 | *** join/#maemo dafox (~dafox@188.206.73.14) |
| 17:18.37 | *** join/#maemo Kabouik_ (~kabouik@176.67.168.144) |
| 17:34.08 | *** join/#maemo Venemo (~venemo@fedora/Venemo) |
| 18:21.03 | *** join/#maemo LauRoman|Alt (~LauRoman@5-14-13-12.residential.rdsnet.ro) |
| 18:37.16 | Maxdamantus | Well, the superfish case is kind of analogous to just including actual software that can be considered malware. |
| 18:37.56 | Maxdamantus | eg, some program that automatically runs and manipulates memory used by web browsers such that it shows websites as being safe when they're not. |
| 18:38.55 | Maxdamantus | It's basically using the same "attack" vector: you control distribution of software, so you can control what the software does, either by including bad/modified software, or by including bad/modified "data" along with that software, such as certificates. |
| 18:39.27 | *** join/#maemo __LauRoman (~LauRoman@5-14-13-12.residential.rdsnet.ro) |
| 18:39.50 | *** join/#maemo jskarvad_ (jskarvad@redhat/jskarvad) |
| 18:40.12 | *** join/#maemo Oksanaa (~Wikiwide@Maemo/community/ex-council/Wikiwide) |
| 18:41.25 | *** join/#maemo _CN_ (~ceene@salem.gmr.ssr.upm.es) |
| 18:41.43 | *** join/#maemo povbot_ (~supybot@office.pov.lt) |
| 18:42.12 | *** join/#maemo yosafbridge (~yosafbrid@68.ip-149-56-14.net) |
| 18:42.13 | *** join/#maemo RedM (~redw@89-67-10-209.dynamic.chello.pl) |
| 18:43.29 | *** join/#maemo till- (~till@vispillo.org) |
| 18:43.35 | *** join/#maemo script_ (~script@mail.scriptkiller.de) |
| 18:49.06 | *** join/#maemo r00t|home (~r00t@port-92-193-3-135.dynamic.qsc.de) |
| 18:49.10 | *** join/#maemo kraft (kraft@gateway/shell/blinkenshell.org/x-kpjowkccsubthgra) |
| 18:50.42 | *** join/#maemo florian (~florian_k@Maemo/community/contributor/florian) |
| 18:51.41 | *** join/#maemo grinsekatze (~andreas@unaffiliated/grinsekatze) |
| 18:53.14 | Maxdamantus | note: the point of the above comments is: superfish is not the fault of any particular trust system, since any trust system is vulnerable to attacks involving control over software distribution. |
| 18:53.57 | *** join/#maemo dafox (~dafox@2a02:a448:c25a:1::1) |
| 18:54.42 | *** join/#maemo troulouliou_div2 (~troulouli@unaffiliated/troulouliou-div2/x-0271439) |
| 18:55.31 | *** join/#maemo troulouliou_div2 (~troulouli@unaffiliated/troulouliou-div2/x-0271439) |
| 19:02.01 | *** join/#maemo LauRoman|Alt (~LauRoman@5-14-13-12.residential.rdsnet.ro) |
| 19:12.15 | *** join/#maemo Kilroo (~Kilroo@173.94.24.151) |
| 19:24.48 | *** join/#maemo BitEvil (~quassel@tor/regular/SpeedEvil) |
| 19:51.45 | *** join/#maemo mavhc (~mavhc@cpc77319-basf12-2-0-cust433.12-3.cable.virginm.net) |
| 20:11.49 | *** join/#maemo infobot (ibot@208.53.50.136) |
| 20:11.49 | *** topic/#maemo is Welcome to #maemo http://maemo.org/intro/ | N9/harmattan related questions please in #harmattan ! | "firmware" see ~lf (or ~tabletsdev ~combined ~emmc ~flasher) sdk: ~sb | http://wiki.maemo.org/Community_Council | Source: http://wiki.maemo.org/Sources | Chanlog: http://mg.pov.lt/maemo-irclog | #maemo-ssu is where the (few) devels and maintainers of the maemo-future meet |
| 20:11.49 | *** mode/#maemo [+v infobot] by ChanServ |
| 20:12.26 | DocScrutinizer05 | https://en.wikipedia.org/wiki/Doc_Holliday |
| 20:17.24 | DocScrutinizer05 | oops, the quote of my colleage actually was >>joerg eats datasheets for breakfast<< |
| 20:18.18 | DocScrutinizer05 | but there's no 3char file extension specific for datasheets ;-D |
| 20:20.15 | DocScrutinizer05 | it's surprising how often the reference to Joe's Garage gets instantly noticed though |
| 20:31.56 | *** join/#maemo peetah (~peetah@cha92-9-82-236-202-86.fbx.proxad.net) |
| 20:38.08 | *** join/#maemo eMHa (~mh@p5089DF5B.dip0.t-ipconnect.de) |
| 21:10.33 | sixwheeledbeast | CSVScrutinizer05 |
| 21:17.36 | *** join/#maemo Kabouik (~kabouik@236.34.200.37.customer.cdi.no) |
| 21:29.32 | *** join/#maemo aloril_ (~aloril@mobile-access-bceeeb-225.dhcp.inet.fi) |
| 21:37.21 | *** join/#maemo Kabouik_ (~kabouik@236.34.200.37.customer.cdi.no) |
| 21:40.34 | DocScrutinizer05 | :-D |
| 21:53.33 | *** join/#maemo RedW (~redw@89-67-10-209.dynamic.chello.pl) |
| 22:12.24 | *** join/#maemo Venemo (~venemo@fedora/Venemo) |
| 22:22.54 | sixwheeledbeast | Wow, a week of no spam on the wiki... well no anything. Maybe I have finally blocked all the rogue IPs... unlikely. |