Re: TLS now supported on openbsd.org?
Just in case someone don't know, there's a non root-required client for Let's Encrypt: https://github.com/diafygi/letsencrypt-nosudo There's some perl scripts too, so you don't have to download python. Also, after you generate and sign the certificate, you don't have to keep the script.
ldconfig & chroot
While checking proot, it would be probably good to have an option for ldconfig to work with specified root directory like it is the case for linux ldconfig. So it would scan and save hints file under specified "root" dir. j.
letsencrypt (Was: Re: TLS now supported on openbsd.org?)
> I dislike the idea. > > For one, it does not stop a MITM by itself. > > In addition, enforced encryption makes it hard to cache and/or use > proper http proxies with the site. > > Purely informative sites don't need TLS. The user can opt to use TLS > if he thinks the content he needs to read is somehow sensitive, or > configure his browser not to use the regular http version if he feels > like doing that. A pure simple redirect does not add much to security > unless the user takes extra steps - but if the user takes extra steps > he does not need a redirect at all. Huh, it seems obscured faces always come out of the woodwork to smash using https whenever there's discussion about it. Regarding letsencrypt, I use it because I'm cheap and lazy and have more domains than patience. Unfortunately the client is horrifying. Here's how I reconcile my cheapness--I figure others might have a better solution than this, so please let me know. (By the way, httpd(8) doesn't support SNI yet--what do you use a web server? I found that apache2's chroot and https combo didn't pass the "can I set this up in less than five minutes" sniff test--I ended up using nginx.) (1) download one of the many letsencrypt shell scripts (I couldn't find any reasonable ones that didn't require bash in a five-minute search), e.g., https://github.com/lukas2511/letsencrypt.sh (2) have a local no-login user that will do nothing but run the aforementioned script in a cronjob, which in turn keeps the certificates (owned by that user) up to date; (2b) configure the user to have access to, say, /var/www/letsencrypt for the "domain-check" phase and set that in WELLKNOWN, with your web server alias /.well-known/acme-challenge to that directory, and have the script keep the certs somewhere in the user's home; (3) have a doas rule for copying certificate parts from that user's certificate directory into, say, /etc/ssl/letsencrypt (owned by that user); or have root do it instead; (4) have a doas rule to reload the web server; (5) have a cronjob (or script from a cronjob) for the dedicated user that runs the letsencrypt script and, if it finishes with success, use doas to copy the certificate parts out and reload the web server. I can share mine if you'd like, but it's just that. In the end, the /etc/ssl/letsencrypt (certificates) and /var/www/letsencrypt (domain validation) directories are effectively owned by the dedicated user, and I assume that they might be filled with crap if the local account somehow gets pwned. Can anybody suggest how to make sure that the certs aren't bogus across cronjob script runs? Another step between the server reload and copy could check-or-reject to make sure that the server doesn't try to load bogusly-crafted certs? Ideally I wouldn't have the letsencrypt actually touch the private keys at all, or run the web server reload, but directly or indirectly a change in cert would need to trigger that, and that's at the mercy of the script anyway. I just assume anything in those directories is toxic. Best, Kristaps
Re: letsencrypt (Was: Re: TLS now supported on openbsd.org?)
- Original Message - > (By the way, httpd(8) doesn't support SNI yet--what do you use a web > server? I found that apache2's chroot and https combo didn't pass the > "can I set this up in less than five minutes" sniff test--I ended up > using nginx.) OpenBSD httpd :) If you need to serve more than one website over HTTPS without SNI, just add the extra domains into the main certificate SAN. Cheers, Marco -- Marco Bonetti
Re: letsencrypt (Was: Re: TLS now supported on openbsd.org?)
Hi Kristaps, Kristaps Dzonsons wrote on Tue, May 10, 2016 at 11:37:42AM +0200: > (1) download ... couldn't find ... didn't require bash > (2) aforementioned script in a cronjob > (2b) user to have access to > (3) doas rule > (4) doas rule > (5) [another?] script from a cronjob You must be joking, Mr. Feynman. Ingo > anything in those directories is toxic.
Re: letsencrypt (Was: Re: TLS now supported on openbsd.org?)
>> (By the way, httpd(8) doesn't support SNI yet--what do you use a >> web server? I found that apache2's chroot and https combo didn't >> pass the "can I set this up in less than five minutes" sniff >> test--I ended up using nginx.) > > OpenBSD httpd :) If you need to serve more than one website over > HTTPS without SNI, just add the extra domains into the main > certificate SAN. Marco, Great! I didn't think that was possible---I always thought SAN was used exclusively for subdomain type things like foo.example.com and moo.example.com in lieu of wildcards. I'll look into this--no more nginx! Best, Kristaps
Re: letsencrypt (Was: Re: TLS now supported on openbsd.org?)
On 2016-05-10, Ingo Schwarze wrote: > Hi Kristaps, > > Kristaps Dzonsons wrote on Tue, May 10, 2016 at 11:37:42AM +0200: > >> (1) download ... couldn't find ... didn't require bash >> (2) aforementioned script in a cronjob >> (2b) user to have access to >> (3) doas rule >> (4) doas rule >> (5) [another?] script from a cronjob > > You must be joking, Mr. Feynman. > Ingo > >> anything in those directories is toxic. > > It's still relatively young and the clients are improving. And even with this sort of thing it's *still* better than a common alternative: Open a web browser. Login to CA. Maybe enter a credit card number. Have them send you an email to "prove" domain ownership. Hope it gets through spam filters (and greylisting if you use it). Generate new key and CSR. Paste in CSR. Maybe wait for CA to approve issuance. Paste new cert into webserver/s. Figure out which chain certs to paste in. Avoid screwing up keys when you change from the old one. Figure out that CA's OCSP responder hasn't updated yet when firefox fails, back out, then reinstate later. etc.
Re: TLS now supported on openbsd.org?
On 2016-05-10, arrowscr...@mail.com wrote: > Just in case someone don't know, there's a non root-required client > for Let's Encrypt: > https://github.com/diafygi/letsencrypt-nosudo The original Python client doesn't need root either, just setup permissions appropriately. (btw, that client is moving from being administered by letsencrypt to EFF and will be renamed to certbot in the future). > Also, after you generate and sign the certificate, you don't have > to keep the script. Validity on the letsencrypt CA is 90 days max. (Partly to restrict usefulness of a bad cert because they don't do CRLs, which are pretty much useless anyway, and partly to encourage users to automate).
Problem with IPSEC between OpenBSD and VMWare vcloud air platform
Hi, I am trying to create an IPSEC tunnel between an OpenBSD 5.8 and VMWare's vcloud air cloud platform. The options that I can set from the vmware side (they provide a GUI) are specific and they are the following: -Local networks -Remote networks -Peer -Pre shared key -Encryption (3DES) On the OpenBSD side I use ipsec.conf and the contents are the following: ike esp from 192.168.66.0/24 to 192.168.55.0/24 peer ABC.DEF.GHI.JKL main auth hmac-sha1 enc 3des group modp1024 quick auth hmac-sha2-256 enc blowfish psk MY-PSK-PHRASE When I start isakmpd and ipsecctl -f /etc/ipsec.conf I always get the following message and the SAs are never created. 133935.717470 Default attribute_unacceptable: AUTHENTICATION_METHOD: got PRE_SHARED, expected RSA_SIG 133935.717808 Default message_negotiate_sa: no compatible proposal found 133935.717916 Default dropped message from ABC.DEF.GHI.JKL port 500 due to notification type NO_PROPOSAL_CHOSEN 133944.988656 Default transport_send_messages: giving up on exchange peer-ABC.DEF.GHI.JKL , no response from peer ABC.DEF.GHI.JKL :500 133945.755693 Default attribute_unacceptable: AUTHENTICATION_METHOD: got PRE_SHARED, expected RSA_SIG 133945.755884 Default message_negotiate_sa: no compatible proposal found 133945.755930 Default dropped message from ABC.DEF.GHI.JKL port 500 due to notification type NO_PROPOSAL_CHOSEN It seems that although I specify that I want a psk to be used, it expects a pub key. Thank you, George
Re: letsencrypt (Was: Re: TLS now supported on openbsd.org?)
On Tue, 10 May 2016, Ingo Schwarze wrote: > Hi Kristaps, > > Kristaps Dzonsons wrote on Tue, May 10, 2016 at 11:37:42AM +0200: > >> (1) download ... couldn't find ... didn't require bash >> (2) aforementioned script in a cronjob >> (2b) user to have access to >> (3) doas rule >> (4) doas rule >> (5) [another?] script from a cronjob > > You must be joking, Mr. Feynman. > Ingo > >> anything in those directories is toxic. Precisely why I've been reluctant to try letsencrypt... "What would be the least insane way to implement this in production?" - Right now, I'm not sure if I should be asking this seriously. K.
Re: TLS now supported on openbsd.org?
Em maio 9, 2016 18:39 Theo de Raadt escreveu: Giancarlo Razzolini wrote: > It is really nice to finally see TLS on openbsd.org. How about redirecting > http to https? I dislike the idea. Let me be more clear, both of you. Those decisions will made by the people (Bob et all) who maintain the back end. They don't need your opinions. Go take your opinions and give them to your BANKS INSTEAD. Theo, I agree with you. After all, if you wanted our opinions, you would have take them a long time ago. I think it is nice you guys (finally) put TLS on the openbsd.org main site. Despite all its flaws, TLS do have valid use cases. An OS site is a perfect example. Also, as you putted, BANKS. Fortunately my country has a pretty decent banking system and they do follow all of the TLS best practices. At least the bank I use, do. OpenBSD's site eventually will catch up with the rest. It is a big win nevertheless. Cheers, Giancarlo Razzolini
Re: TLS now supported on openbsd.org?
Em maio 10, 2016 1:29 Bob Beck escreveu: And statements like this - and people that think this is a good idea, are why I spoof DNS answers in bars and coffee shops, and why I don't read misc@. This is never a good idea, unless you want the connections intercepted and MITM'ed. I don't see the issue with this Bob. Of course it means the first access is the one with very high value. But as it is with HPKP, and as it is with SSH itself. I see that you guys are working on having openbsd included in HTTPS Everywhere and all. But it still leaves it up to the user. If you put HSTS on top of a one time redirect, the client will never again access the site using http. It is a concession. One that you don't seem keen to make. And, on a second thought, I only care for the anon csv page where you have the ssh host keys. The rest of the site can be left unencrypted. Until every UA is changed to first try TLS and *only then* fall back to clear text http, this kind of measure has its uses. Cheers, Giancarlo Razzolini
Re: TLS now supported on openbsd.org?
On Tue, 10 May 2016, Giancarlo Razzolini wrote: > Until every UA is changed to first try TLS and *only then* fall back > to clear text http, this kind of measure has its uses. This is of limited usefulness. All you need to do (as a mitm) is to block the connection on port 443, client will now automagically fall back to using 80 and plain text... It's even easier than filtering out STARTTLS for SMTP. Go google some, why opportunistic encryption is a bad idea. K.
Re: TLS now supported on openbsd.org?
Em maio 10, 2016 9:07 Kamil Cholewiński escreveu: On Tue, 10 May 2016, Giancarlo Razzolini wrote: This is of limited usefulness. All you need to do (as a mitm) is to block the connection on port 443, client will now automagically fall back to using 80 and plain text... It's even easier than filtering out STARTTLS for SMTP. Go google some, why opportunistic encryption is a bad idea. K. Limited? Sure. STARTTLS is a bad idea and I didn't meant that by any circumstance. Opportunistic encryption is a bad idea. As it is DNS, as it is DNSSEC, as it is TLS. But it is what he have. For now. Ironically, google does it, facebook does it, twitter does it, pretty much every freaking big site does it. Don't beat a dead horse anymore. As I said, all I cared about was the anon cvs page. Which now I can access over TLS, even if I have to guess it is accessible over TLS. Cheers, Giancarlo Razzolini
Re: ldconfig & chroot
On Tue, May 10, 2016 at 05:23:07AM -0400, Jiri B wrote: > While checking proot, it would be probably good to have an > option for ldconfig to work with specified root directory > like it is the case for linux ldconfig. So it would scan and > save hints file under specified "root" dir. What would that accomplish ? the current code is perfectly fine.
Re: letsencrypt (Was: Re: TLS now supported on openbsd.org?)
> It's still relatively young and the clients are improving. I actually don't think they are improving. I don't see any with priviledge seperation, nor any which could plausibly be pledged.
[SOLVED]Re: Claws-mail without Dbus
2016-05-10 01:20 に Jeremie Courreges-Anglas さんは書きました: m...@pmars.jp writes: Hi, Thanks a lot for all the really nice job you re doing here. I'm trying to install Claws-mail without Dbus but that seems not possible. The ports tree tries to provide packages usable by most. What if another user wants claws-mail linked against dbus, but not against xz? Is there a way to do that via pkg_add or pkg_delete? I saw smtg on the man with the -D option and 'libdepends' value, stating the lib might not be fulfilled; would it be the way Once you start to use this kind of option, you're on your own. (I doubt as Dbus is not a lib) ? dbus is also a lib. I tried to ftp only the claws package and nulled $PKG_PATH, that didn't work. Pkg_add told me it needs claws' dependencies; ie. dbus and its lib(and a wrapper named enchant). Obviously dbus is needed, since by default claws-mail links against it. Even if you untarred the package and installed claws manually, you wouldn't be able to run it. Below are info about the systm Im using, if you need more, please tell me Looks like you have packages that depend on dbus, but dbus doesn't appear in the list you provide. That kind of custom setup isn't supported. You'd better reconsider the reasons why you do not want dbus installed in the first place. Thanks a lot for your answer. Actually, the tarball, that what I was thinking as a last resort. Not the pkg_add one actually, the one from claws-mail.org. I totally understand and agree with OpenBSD's policy about creating pkg usable by most. Just Im trying to learn and want less middle-man as possible for the time being. Thanks again and Bye.
malloc.conf on BeagleBone Black
I started using the wonderfull malloc.conf, setting it to CFGJPRSU. This works on amd64 and macppc and i386, but on a freshly upgraded current/armv7 (a BeagleBone Black), some programs report malloc() warning: unknown char in MALLOC_OPTIONS Each of the flags is documented in the malloc.conf(5) manpage. Is there something specific about this on the BBB? Jan
Re: TLS now supported on openbsd.org?
On Tue, May 10, 2016 at 11:39:44AM +, Giancarlo Razzolini wrote: > Em maio 10, 2016 1:29 Bob Beck escreveu: > > > > And statements like this - and people that think this is a good idea, > > are why I spoof DNS answers in bars and coffee shops, and why I don't > > read misc@. This is never a good idea, unless you want the > > connections intercepted and MITM'ed. > > > > I don't see the issue with this Bob. Of course it means the first access is > the one with very high value. But as it is with HPKP, and as it is with SSH > itself. I see that you guys are working on having openbsd included in HTTPS > Everywhere and all. But it still leaves it up to the user. If you put HSTS on > top of a one time redirect, the client will never again access the site using > http. It is a concession. One that you don't seem keen to make. And, on a > second thought, I only care for the anon csv page where you have the ssh host > keys. The rest of the site can be left unencrypted. Until every UA is changed > to first try TLS and *only then* fall back to clear text http, this kind of > measure has its uses. We are not working on the HTTPS Everywhere rules for *.openbsd.org. The guy who sent the pull request is not part of the project. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: problem with packages after update
To report back. After waiting a day for packages to be in association with snapshot, it all installed fine. Thanks all, who helped me to understand an issue. Zoran
Re: malloc.conf on BeagleBone Black
hans schreef op 10 mei 2016 17:12:23 CEST: >I started using the wonderfull malloc.conf, >setting it to CFGJPRSU. This works on amd64 and macppc and i386, >but on a freshly upgraded current/armv7 (a BeagleBone Black), >some programs report > > malloc() warning: unknown char in MALLOC_OPTIONS > >Each of the flags is documented in the malloc.conf(5) manpage. >Is there something specific about this on the BBB? > > Jan Well, that's a lot of flags, things will get slow Some are redundant (included in S), some are already on by default. I would advise just to use S and be done with it. Why you do not get the expected results on armv7 I do not know. My guesses are: older version of libc or typo. Eliminate flags until you find the offending one. -Otto
Re: malloc.conf on BeagleBone Black
On May 10 18:02:12, o...@drijf.net wrote: > hans schreef op 10 mei 2016 17:12:23 CEST: > >I started using the wonderfull malloc.conf, > >setting it to CFGJPRSU. This works on amd64 and macppc and i386, > >but on a freshly upgraded current/armv7 (a BeagleBone Black), > >some programs report > > > > malloc() warning: unknown char in MALLOC_OPTIONS > > > >Each of the flags is documented in the malloc.conf(5) manpage. > >Is there something specific about this on the BBB? > > > > Jan > > > Well, that's a lot of flags, things will get slow Some are redundant > (included in S), some are already on by default. I would advise just to use S > and be done with it. > > Why you do not get the expected results on armv7 I do not know. > My guesses are: older version of libc or typo This is current/armv7 (May 8). I have double hecked the string. > Eliminate flags until you find the offending one. Hm, it's the C (canaries). The rest is OK. Is there something about canaries on the BBB? Jan
Re: malloc.conf on BeagleBone Black
hans wrote: > On May 10 18:02:12, o...@drijf.net wrote: > > hans schreef op 10 mei 2016 17:12:23 CEST: > > >I started using the wonderfull malloc.conf, > > >setting it to CFGJPRSU. This works on amd64 and macppc and i386, > > >but on a freshly upgraded current/armv7 (a BeagleBone Black), > > >some programs report > > > > > > malloc() warning: unknown char in MALLOC_OPTIONS > > > > > >Each of the flags is documented in the malloc.conf(5) manpage. > > >Is there something specific about this on the BBB? > > > > > > Jan > > > > > > Well, that's a lot of flags, things will get slow Some are redundant > > (included in S), some are already on by default. I would advise just to use > > S and be done with it. > > > > Why you do not get the expected results on armv7 I do not know. > > My guesses are: older version of libc or typo > > This is current/armv7 (May 8). > I have double hecked the string. > > > Eliminate flags until you find the offending one. > > Hm, it's the C (canaries). The rest is OK. > Is there something about canaries on the BBB? if it's only some programs, then it's because those are older programs.
Re: malloc.conf on BeagleBone Black
On May 10 12:29:16, t...@tedunangst.com wrote: > hans wrote: > > On May 10 18:02:12, o...@drijf.net wrote: > > > hans schreef op 10 mei 2016 17:12:23 CEST: > > > >I started using the wonderfull malloc.conf, > > > >setting it to CFGJPRSU. This works on amd64 and macppc and i386, > > > >but on a freshly upgraded current/armv7 (a BeagleBone Black), > > > >some programs report > > > > > > > > malloc() warning: unknown char in MALLOC_OPTIONS > > > > > > > >Each of the flags is documented in the malloc.conf(5) manpage. > > > >Is there something specific about this on the BBB? > > > > > > > > Jan > > > > > > > > > Well, that's a lot of flags, things will get slow Some are redundant > > > (included in S), some are already on by default. I would advise just to > > > use S and be done with it. > > > > > > Why you do not get the expected results on armv7 I do not know. > > > My guesses are: older version of libc or typo > > > > This is current/armv7 (May 8). > > I have double hecked the string. > > > > > Eliminate flags until you find the offending one. > > > > Hm, it's the C (canaries). The rest is OK. > > Is there something about canaries on the BBB? > > if it's only some programs, then it's because those are older programs. Yes they are. I will get back after they recompile. Thanks. Jan
Re: letsencrypt (Was: Re: TLS now supported on openbsd.org?)
On 2016-05-10, Theo de Raadt wrote: >> It's still relatively young and the clients are improving. > > I actually don't think they are improving. > > I don't see any with priviledge seperation, nor any which could > plausibly be pledged. For months there wasn't anything other than the official client. After the service started operating and showed itself to not be vapourware people started writing their own, but obviously the ones that were ready to share early were mostly quick hacks. It's not priviledge-separated (though like most of them can be run as an unpriviledged user given a little thought), but there's one written in go (acmetool) which seems cleaner than most. (Pity it's in a language with an annoying-to-build/package ecosystem but at least it's not another one in unportable bash...) I'd be happy to be proved wrong but I don't think we're very likely to see privsep unless it comes from someone familiar with OpenBSD. I don't know why but very few seem to use these techniques.
Re: letsencrypt (Was: Re: TLS now supported on openbsd.org?)
> > I don't see any with priviledge seperation, nor any which could > > plausibly be pledged. > > For months there wasn't anything other than the official client. After > the service started operating and showed itself to not be vapourware > people started writing their own, but obviously the ones that were > ready to share early were mostly quick hacks. > > It's not priviledge-separated (though like most of them can be run as an > unpriviledged user given a little thought), "as an unpriviledged user" is terribly low bar. Can it be run with parts chrooted? If not, then where is the actual filesystem safety? Many people not capable of setting up what you propose. Hence, they won't. There will be little or no thought. Many people are running these clients as root, connecting to a server on the internet that probably has the same code quality. > but there's one written in go (acmetool) which seems cleaner than > most. (Pity it's in a language with an annoying-to-build/package > ecosystem but at least it's not another one in unportable bash...) And where is the filesystem safety? The system administrator must structure safe use themselves? And surely the documentation advises that, and the program won't work if you use it unsafely? I am very sceptical. If the domain knowledge required to use a subsystem is too high, it will be misused by many. There is a fan club pushing for letsencrypt without recognizing the unsafe practices everyone is now following on their systems, as a result of this push using crap prototypes. > I'd be happy to be proved wrong but I don't think we're very likely to > see privsep unless it comes from someone familiar with OpenBSD. I don't > know why but very few seem to use these techniques. Of course. But until that happens, most of the people using the existing let encrypt clients are Sheep.
Re: TLS now supported on openbsd.org?
> > Also, after you generate and sign the certificate, you don't have > > to keep the script. > > Validity on the letsencrypt CA is 90 days max. (Partly to restrict > usefulness of a bad cert because they don't do CRLs, which are pretty > much useless anyway, and partly to encourage users to automate). Ugghhh, I was fearing that their automate and security mantra might clash, but they don't seem to mention it up front. 365 days already annoys me especially as I intend to use OpenSSH for anything particularly important and cryptanalysis is not a problem for years on a low traffic site. >> I only care for the anon csv page where you have the ssh host >> keys. The rest of the site can be left unencrypted. Until every UA is changed >> to first try TLS and *only then* fall back to clear text http, this kind of >> measure has its uses. You enforce SSL for data submissions, a user checking keys has to check the domain in any case and hope the browser domain matching code is secure too (yes there has been atleast one firefox bug there) even before considering the DNS system. Let's encrypt as in let's make certificates more widely available is good. Let's encrypt as in all sites should encrypt all connections is actually a negative for any professionally run outfit even when ignoring DOS attacks or servers that don't have AES acceleration or I guess ChaCha/Salsa acceleration in the future. It's main unrealised potential benefit is; add *some* security by default to all those insecure wordpress logins. TLS by default (for idiots) but not everywhere would be sensible/optimal. The method appears to be to eventually use a stick to make it commercially required for most organisations but this hurts the professional outfits. The other alledged benefit is the alledged case that not one trustable ISP is providing service in an area, haha. So use a VPN, as comodo's software offer for free in public networks. I suspect another agenda like control of advertising or selling DOS protection or acceleration services. I'll be glad if akamai stops getting in the way of having some confidence in https checks on windows downloads for example though. -- KISSIS - Keep It Simple So It's Securable
Re: ldconfig & chroot
On Tue, May 10, 2016 at 02:38:37PM +0200, Marc Espie wrote: > On Tue, May 10, 2016 at 05:23:07AM -0400, Jiri B wrote: > > While checking proot, it would be probably good to have an > > option for ldconfig to work with specified root directory > > like it is the case for linux ldconfig. So it would scan and > > save hints file under specified "root" dir. > > What would that accomplish ? the current code is perfectly fine. Thanks for answer. I'd like to ask you if there is any potentional security issue to have either ldconfig binary inside chroots or full coppy of hints from base os inside chroots. This was my exact concern. j.
Re: TLS now supported on openbsd.org?
On 2016-05-10, Kevin Chadwick wrote: >> > Also, after you generate and sign the certificate, you don't have >> > to keep the script. >> >> Validity on the letsencrypt CA is 90 days max. (Partly to restrict >> usefulness of a bad cert because they don't do CRLs, which are pretty >> much useless anyway, and partly to encourage users to automate). > > Ugghhh, I was fearing that their automate and security mantra might > clash, but they don't seem to mention it up front. 365 days already > annoys me especially as I intend to use OpenSSH for anything > particularly important and cryptanalysis is not a problem for years on > a low traffic site. It's not about cryptanalysis, it's about reducing impact from compromised hosts and from the weak authentication systems that are done on all the "low value" DV CAs. (specifically this one is "requester had access to cause files to be served at an http server running at the address pointed to by DNS at the time it was requested" so a security failure at any of a number of points would allow access). > You enforce SSL for data submissions, a user checking keys has to check > the domain in any case and hope the browser domain matching code is > secure too (yes there has been atleast one firefox bug there) even > before considering the DNS system. Still, browsers are a higher bar than the control panels and front line support staff at a typical cheap domain host. > It's main unrealised potential benefit is; add *some* security by > default to all those insecure wordpress logins. That's a terrible reason. And actually it's "make those insecure CMS sites look more like they might be secure" when they're no such thing. Because people have been trained into equating https with security. Which is just plain wrong.
white noise about broken manpage (web) links
Dear Misc, I could not find a separate mailing list for openiked. Hence posting here. web manpage links appear to be broken on: 1) http://www.openiked.org/ 2) http://www.openiked.org/manual.html The referenced links are 1A) http://www.openbsd.org/cgi-bin/man.cgi?query=isakmpd 2A) http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/iked.8 2B) http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man5/iked.conf.5 2C) http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/ikectl.8 I get a "500 Internal server error... OpenBSD httpd" Unrelated - I have gotten the same error when clicking links on 3rd party websites like daemonforums.org I promise to submit diffs when I am more confident of submitting them. Please ignore if trivial. Vivek
Re: white noise about broken manpage (web) links
You need to complain at reyk - since these web pages are not in the openbsd www/ tree they didn't get fixed when we converted to man.openbsd.org On Tue, May 10, 2016 at 10:52 PM, Vivek Vinod wrote: > Dear Misc, > > I could not find a separate mailing list for openiked. Hence posting here. > > web manpage links appear to be broken on: > 1) http://www.openiked.org/ > 2) http://www.openiked.org/manual.html > > The referenced links are > 1A) http://www.openbsd.org/cgi-bin/man.cgi?query=isakmpd > > 2A) http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/iked.8 > 2B) http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man5/iked.conf.5 > 2C) http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/ikectl.8 > > I get a "500 Internal server error... OpenBSD httpd" > > Unrelated - I have gotten the same error when clicking links on 3rd > party websites like daemonforums.org > > I promise to submit diffs when I am more confident of submitting them. > > Please ignore if trivial. > > Vivek
