Re: OT:Password strength
On Sun, November 30, 2014 8:09 pm, Eric Furman wrote: On Sun, Nov 30, 2014, at 12:48 AM, Nick Holland wrote: lots snipped Then there is the system where it is stored. If you are working on a stock Solaris 9 or AIX system with the default settings, only the first eight chars are used, so the random string is much better than mylittle, and if you, like most people, reuse passwords or don't know that the target system only uses the first eight characters, you can end up using a trivial pw that you thought was really good. Yes, part of the reason for asking this question was that I am aware that some authentication schemes only use the first 8 characters. Is there any way of knowing if they do ignore any characters after the first eight? sure. after setting your password to more than eight characters, try logging in by entering just the first eight characters. Are authentication schemes that don't recognize more than eight characters still common? try it and see. One of my banking sites won't except certain special characters. Like $, %, ? Which messes up my best short passwords that I actually remember. i too find it annoying when the set of valid password characters is not listed somewhere easy for the user to find. -wes
openbsdstore: enable javascript and buy something or gtfo
In my browser of choice, configured sensibly, this is all that can be seen at openbsdstore.com and openbsdeurope.com: | The OpenBSD Store | If you have JavaScript disabled you will not be able to order from | this site... And yes, it literally ends with an ellipsis. Strangely enough, this doesn't incline me to enable javascript. -wes
Re: openbsdstore: enable javascript and buy something or gtfo
On Fri, 3 Oct 2014, Martin Schröder wrote: 2014-10-03 16:09 GMT+02:00 david...@ling.ohio-state.edu: Strangely enough, this doesn't incline me to enable javascript. Why? Don't you trust the store? Heh, literally blind trust, eh? What store? You call it a store. And I did expect it to be a store of some kind, since openbsd.org/orders.html links to it as the sole source for CDs. But the failure to provide minimal contact info, not to mention any descriptive content, doesn't inspire confidence. Whoever is responsible for it, if they can't be troubled to put up an accessible website, then it really doesn't matter whether I employ Hanlon's razor or not. Whether this is a case of malice or incompetence, my response is the same. -wes
Re: openbsdstore: enable javascript and buy something or gtfo
On Fri, 3 Oct 2014, Bryan Steele wrote: On Fri, Oct 03, 2014 at 10:09:36AM -0400, david...@ling.ohio-state.edu wrote: In my browser of choice, configured sensibly, this is all that can be seen at openbsdstore.com and openbsdeurope.com: | The OpenBSD Store | If you have JavaScript disabled you will not be able to order from | this site... And yes, it literally ends with an ellipsis. Strangely enough, this doesn't incline me to enable javascript. -wes So, you visit an order page likely content on providing your billing information and shipping address, but it's the use of Javascript that sways your final decision to order? Who said anything about an order page? Who said anything about final decisions? The text provided gave me no information upon which to base any decision of that kind. As I made perfectly clear in my post, the accessible content on the website is a single, elided sentence. Why should I enable javascript to obtain basic information about a website? Really, it's quite an achievement, seeing as even Facebook pages aren't completely void of content when viewed without javascript. -wes
Re: openbsdstore: enable javascript and buy something or gtfo
On Fri, 3 Oct 2014, Theo de Raadt wrote: So easy to be critical. Sure. And some criticism happens to be useful. Some say it's even more useful than wagon-circling.
Re: openbsdstore: enable javascript and buy something or gtfo
On Fri, 3 Oct 2014, Theo de Raadt wrote: Who said anything about an order page? Who said anything about final decisions? The text provided gave me no information upon which to base any decision of that kind. As I made perfectly clear in my post, the accessible content on the website is a single, elided sentence. Why should I enable javascript to obtain basic information about a website? Really, it's quite an achievement, seeing as even Facebook pages aren't completely void of content when viewed without javascript. You know who to mail, to help get that improved. No, I actually don't. See my first post. I could guess, but I didn't feel like guessing. But instead you brought your complaint to misc. Indeed. You have an agenda. Sure do. I had reason to distrust the website, as I've explained. But I have no reason to distrust this listserv. -wes
Re: openbsdstore: enable javascript and buy something or gtfo
On Fri, 3 Oct 2014, david...@ling.ohio-state.edu wrote: On Fri, 3 Oct 2014, Theo de Raadt wrote: But instead you brought your complaint to misc. Indeed. You have an agenda. Sure do. I had reason to distrust the website, as I've explained. But I have no reason to distrust this listserv. I'll elaborate a little, in the interest of clarity, and then leave the thread. I can't know what interest openbsdeurope has in requiring users to enable JS to obtain any information from their website. But it occurred to me that such an interest *could* conceivably conflict with the interests of the openbsd project, and perhaps some of its users. So I shared what I had noticed, with the project and its users here. In good faith. Take care. -wes
Re: openbsdstore: enable javascript and buy something or gtfo
On Fri, 3 Oct 2014, Matti Karnaattu wrote: Why should I enable javascript to obtain basic information about a website? Why do not keep Javascript all time enabled? Keeping Javascript disabled is like disabling programmability from shell. What is the idea? You're making a joke, maybe? *I* choose what programs my shell executes. But when I visit a webpage on the internet with javascript enabled, someone *else* chooses what programs are executed. So I don't enable javascript unless there's a good reason. And, for my purposes, there almost never is a good reason. -wes -- It's a universal symbol, a man and a woman together. It's a restroom. --- some guy sitting next to me on an airplane
Re: Bypassing ssh for ipsec transport flows
On Feb 8, 2011, at 10:20 AM, G Douglas Davidson wrote: I'm attempting to exclude ssh traffic from host to host IPSec transport traffic. And not having much success on the OpenBSD side (OpenBSD to Racoon.) Here's what ipsec.conf looks like: --- ipsec.conf --- flow esp proto tcp from any to any port 22 type bypass ike esp transport from 10.222.0.1 to 10.222.0.100 \ local 10.222.0.1 peer 10.222.0.100 \ main auth hmac-sha1 enc aes group modp1024 \ quick auth hmac-sha1 enc aes group modp1024 --- end ipsec.conf --- I've attempted to define the manual bypass flow in different places, but whenever the transport connection takes place, it seems that the flow set up by the ike line takes precedence: --- ipsecctl -s output --- # ipsecctl -s all FLOWS: flow esp in from 10.222.0.100 to 10.222.0.1 peer 10.222.0.100 srcid 10.222.0.1/32 dstid 10.222.0.100/32 type use flow esp out from 10.222.0.1 to 10.222.0.100 peer 10.222.0.100 srcid 10.222.0.1/32 dstid 10.222.0.100/32 type require flow esp in proto tcp from ::/0 port ssh to ::/0 type bypass flow esp out proto tcp from ::/0 to ::/0 port ssh type bypass flow esp in proto tcp from 0.0.0.0/0 port ssh to 0.0.0.0/0 type bypass flow esp out proto tcp from 0.0.0.0/0 to 0.0.0.0/0 port ssh type bypass SAD: esp transport from 10.222.0.1 to 10.222.0.100 spi 0x0b68c273 auth hmac-sha1 enc aes esp transport from 10.222.0.100 to 10.222.0.1 spi 0xf43c72ff auth hmac-sha1 enc aes --- end ipsecctl -s output --- The result is that non-ssh traffic properly uses the esp transport flow: --- tcpdump with icmp ping --- # tcpdump -i vr1 -n host 10.222.0.100 tcpdump: listening on vr1, link-type EN10MB 10:11:49.244065 esp 10.222.0.100 10.222.0.1 spi 0xf43c72ff seq 41 len 116 10:11:49.244400 esp 10.222.0.1 10.222.0.100 spi 0x0b68c273 seq 55 len 116 10:11:50.244212 esp 10.222.0.100 10.222.0.1 spi 0xf43c72ff seq 42 len 116 10:11:50.244549 esp 10.222.0.1 10.222.0.100 spi 0x0b68c273 seq 56 len 116 --- end tcpdump --- Yet ssh traffic is coming in unencrypted, bypassing ipsec, but it sent back out via the ipsec channel (not bypassing.) --- tcpdump with ssh traffic --- 10:14:26.959883 10.222.0.100.49165 10.222.0.1.22: S 831634158:831634158(0) win 65535 mss 1460,nop,wscale 3,nop,nop,timestamp 609281851 0,sackOK,eol (DF) 10:14:26.960191 esp 10.222.0.1 10.222.0.100 spi 0x0b68c273 seq 58 len 84 10:14:26.960531 10.222.0.100.49165 10.222.0.1.22: . ack 4184984667 win 65535 nop,nop,timestamp 609281851 1116915592 (DF) 10:14:27.025871 esp 10.222.0.1 10.222.0.100 spi 0x0b68c273 seq 59 len 100 (DF) 10:14:27.026220 10.222.0.100.49165 10.222.0.1.22: . ack 22 win 65535 nop,nop,timestamp 609281852 1116915592 (DF) --- end tcpdump --- I can't seem to find how to affect the order of flow processing. Can the order the changed? And is it a first match or first most specific match? Bit confused. The idea is I'd like to be able to ssh to any box and fix a potentially broken ipsec setup. Thanks for any help! --doug The solution to this issue requires that flows be specified manually, and isakmpd must be run with the -Ka flags. When ipsec.conf is processed, the most recent line processed becomes the first one checked, potentially overriding other rules (what happens when isakmpd is allowed to create flows). So specifying flows manually, in reverse order from how one wishes them to be checked, where the first match encountered determines what happens, is the way to go. #In this example, the ssh bypasses will be checked first, and so ssh traffic will not occur over ipsec. flow esp in from 10.222.1.13 to 10.222.0.1 type use flow esp out from 10.222.0.1 to 10.222.1.13 type require flow esp in proto tcp from 10.222.1.13 to 10.222.0.1 port ssh type bypass flow esp in proto tcp from 10.222.1.13 port ssh to 10.222.0.1 type bypass And, in messing around with this, it's even nicer to set up a default tunnel to the gateway for non local subnet traffic (and the source gateway to host traffic), while allowing local hosts with ipsec set up to use transport (rules exists on non-gateway hosts), and finally having a default for traffic between local hosts that are not on ipsec to use a bypass rule (again, rule exists on non-gateway hosts). I also set up a bypass rule for traffic moving between ipsec ports. This may be necessary with tunnels having endpoints over a local subnet. This seems to be a nice setup to protect wireless traffic via IPSec. Something along these lines on the OpenBSD gateway. flow esp from any to 10.222.1.13 peer 10.222.1.13 type require flow esp out proto udp from 10.222.0.1 port 500 to 10.222.1.13 port 500 type bypass flow esp in proto udp from 10.222.1.13 port 500 to 10.222.0.1 port 500 type bypass flow esp out proto tcp from 10.222.0.1 to 10.222.1.13 port 22 type bypass flow esp in proto tcp from 10.222.1.13 port 22 to 10.222.0.1 type bypass flow esp in proto tcp from 10.222.1.13 to 10.222.0.1 port 22 type
Bypassing ssh for ipsec transport flows
I'm attempting to exclude ssh traffic from host to host IPSec transport traffic. And not having much success on the OpenBSD side (OpenBSD to Racoon.) Here's what ipsec.conf looks like: --- ipsec.conf --- flow esp proto tcp from any to any port 22 type bypass ike esp transport from 10.222.0.1 to 10.222.0.100 \ local 10.222.0.1 peer 10.222.0.100 \ main auth hmac-sha1 enc aes group modp1024 \ quick auth hmac-sha1 enc aes group modp1024 --- end ipsec.conf --- I've attempted to define the manual bypass flow in different places, but whenever the transport connection takes place, it seems that the flow set up by the ike line takes precedence: --- ipsecctl -s output --- # ipsecctl -s all FLOWS: flow esp in from 10.222.0.100 to 10.222.0.1 peer 10.222.0.100 srcid 10.222.0.1/32 dstid 10.222.0.100/32 type use flow esp out from 10.222.0.1 to 10.222.0.100 peer 10.222.0.100 srcid 10.222.0.1/32 dstid 10.222.0.100/32 type require flow esp in proto tcp from ::/0 port ssh to ::/0 type bypass flow esp out proto tcp from ::/0 to ::/0 port ssh type bypass flow esp in proto tcp from 0.0.0.0/0 port ssh to 0.0.0.0/0 type bypass flow esp out proto tcp from 0.0.0.0/0 to 0.0.0.0/0 port ssh type bypass SAD: esp transport from 10.222.0.1 to 10.222.0.100 spi 0x0b68c273 auth hmac-sha1 enc aes esp transport from 10.222.0.100 to 10.222.0.1 spi 0xf43c72ff auth hmac-sha1 enc aes --- end ipsecctl -s output --- The result is that non-ssh traffic properly uses the esp transport flow: --- tcpdump with icmp ping --- # tcpdump -i vr1 -n host 10.222.0.100 tcpdump: listening on vr1, link-type EN10MB 10:11:49.244065 esp 10.222.0.100 10.222.0.1 spi 0xf43c72ff seq 41 len 116 10:11:49.244400 esp 10.222.0.1 10.222.0.100 spi 0x0b68c273 seq 55 len 116 10:11:50.244212 esp 10.222.0.100 10.222.0.1 spi 0xf43c72ff seq 42 len 116 10:11:50.244549 esp 10.222.0.1 10.222.0.100 spi 0x0b68c273 seq 56 len 116 --- end tcpdump --- Yet ssh traffic is coming in unencrypted, bypassing ipsec, but it sent back out via the ipsec channel (not bypassing.) --- tcpdump with ssh traffic --- 10:14:26.959883 10.222.0.100.49165 10.222.0.1.22: S 831634158:831634158(0) win 65535 mss 1460,nop,wscale 3,nop,nop,timestamp 609281851 0,sackOK,eol (DF) 10:14:26.960191 esp 10.222.0.1 10.222.0.100 spi 0x0b68c273 seq 58 len 84 10:14:26.960531 10.222.0.100.49165 10.222.0.1.22: . ack 4184984667 win 65535 nop,nop,timestamp 609281851 1116915592 (DF) 10:14:27.025871 esp 10.222.0.1 10.222.0.100 spi 0x0b68c273 seq 59 len 100 (DF) 10:14:27.026220 10.222.0.100.49165 10.222.0.1.22: . ack 22 win 65535 nop,nop,timestamp 609281852 1116915592 (DF) --- end tcpdump --- I can't seem to find how to affect the order of flow processing. Can the order the changed? And is it a first match or first most specific match? Bit confused. The idea is I'd like to be able to ssh to any box and fix a potentially broken ipsec setup. Thanks for any help! --doug
openbdp problem with set localpref on match
I'm having a heck of a time with openbgp on openbsd 3.7. I am attempting to set the localpref for a network and somehow it does not appear to be happening. I've tried: network 192.168.1.0/24 set localpref 200 and match to any prefix 192.168.1.0/24 set localpref 200 and I can't seem to make things happen. If I do a: freeza# bgpctl show rib 192.168.1.0/24 flags: * = Valid, = Selected, I = via IBGP, A = Announced origin: i = IGP, e = EGP, ? = Incomplete flags destination gateway lpref med aspath origin AI* 192.168.1.0/24 0.0.0.0200 0 i It looks like the localpref has been set. But checking out the update produced by the dump updates out command, I don't see the localpref set. Also, looking at each of our two upstreams, the localpref is still 100. I've successfully used the match statement to a specific upstream to set a community value, so I'm just not sure what the issue is with this. Any help appreciated. -- G. Douglas Davidson | CityNet, Inc. [EMAIL PROTECTED] | Pittsburgh, PA voice: 412.481.5406 | fax: 412.431.1315
Re: OpenBGPD - advertised-routes (more)
On Jul 29, 2005, at 4:18 PM, Claudio Jeker wrote: On Fri, Jul 29, 2005 at 01:23:27PM -0400, G Douglas Davidson wrote: I'm having an issue announcing a NO_EXPORT network to our upstream and I'd like a way to prove that I am in fact sending the network in question (if in fact I am). It seems the log updates does not apply to sent updates, just received. Any suggestions appreciated. I utilized the dump updates feature as follows: dump updates out /tmp/updates-out-%H%M 300 And in looking at the output, we are in fact not announce the network in question. However a bgpctl network show indicates that we are announcing the network in question. There are no filters in place. The only things that appears different for this network versus other networks we announce are: 1. This network (a /24) is part of a larger network (/20) that we announce. 2. This network is announced with the NO_EXPORT community. 3. This network is also announced by another provider and is in our bgp table. Any help would be appreciated! Currently it is only possible to set the NO_EXPORT community on outgoing updates (match to rules). This is probably not expeceted behaviour. I will have a look at it after I have finaly rewritten the bgp filter stuff. Looks like adding NO_EXPORT via the rules match worked. Thanks! -- G. Douglas Davidson | CityNet, Inc. [EMAIL PROTECTED] | Pittsburgh, PA voice: 412.481.5406 | fax: 412.431.1315
OpenBGPD - advertised-routes (more)
I'm having an issue announcing a NO_EXPORT network to our upstream and I'd like a way to prove that I am in fact sending the network in question (if in fact I am). It seems the log updates does not apply to sent updates, just received. Any suggestions appreciated. I utilized the dump updates feature as follows: dump updates out /tmp/updates-out-%H%M 300 And in looking at the output, we are in fact not announce the network in question. However a bgpctl network show indicates that we are announcing the network in question. There are no filters in place. The only things that appears different for this network versus other networks we announce are: 1. This network (a /24) is part of a larger network (/20) that we announce. 2. This network is announced with the NO_EXPORT community. 3. This network is also announced by another provider and is in our bgp table. Any help would be appreciated! -- G. Douglas Davidson | CityNet, Inc. [EMAIL PROTECTED] | Pittsburgh, PA voice: 412.481.5406 | fax: 412.431.1315
OpenBGPD - advertised-routes
I'm having an issue announcing a NO_EXPORT network to our upstream and I'd like a way to prove that I am in fact sending the network in question (if in fact I am). It seems the log updates does not apply to sent updates, just received. Any suggestions appreciated. -- G. Douglas Davidson | CityNet, Inc. [EMAIL PROTECTED] | Pittsburgh, PA voice: 412.481.5406 | fax: 412.431.1315
bgpd and community attribute setting
I'm running bgpd on openbsd version 3.5 (I know, time to upgrade.) I'm attempting to create a network statement that sets the community value to NO_EXPORT for a network and I'm getting syntax errors. I've tried: network 192.168.1.0/24 set community 65535:65281 And I get: Jul 25 07:43:51 freeza bgpd[845]: /etc/bgpd.conf:20: syntax error I've also tried setting things up with the network statement separate: network 192.168.1.0/24 and adding this to the filter section: match prefix 192.168.1.0/24 set community 65535:65281 And again, there is the syntax error. I see that in the latest version I can: network 192.168.1.0/24 set community NO_EXPORT but I'd need to upgrade for that (it's on the agenda.) Thanks for any assistance! -- G. Douglas Davidson | CityNet, Inc. [EMAIL PROTECTED] | Pittsburgh, PA voice: 412.481.5406 | fax: 412.431.1315
Re: bgpd and community attribute setting
On Jul 25, 2005, at 10:49 AM, Henning Brauer wrote: * G Douglas Davidson [EMAIL PROTECTED] [2005-07-25 16:30]: I'm running bgpd on openbsd version 3.5 (I know, time to upgrade.) I'm attempting to create a network statement that sets the community value to NO_EXPORT for a network and I'm getting syntax errors. support for setting communities was added post-3.5. but I'd need to upgrade for that (it's on the agenda.) well a current bgpd should compile on an older OpenBSD with minor adjustments - but you really want to upgrade, there were changes wrt the routing table and kernel memory usage that help bgpd machines a lot. -- BS Web Services, http://www.bsws.de/ OpenBSD-based Webhosting, Mail Services, Managed Servers, ... Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie) Thanks for the info. I think I'll go with the update and keep it simple. Many Thanks! -- G. Douglas Davidson | CityNet, Inc. [EMAIL PROTECTED] | Pittsburgh, PA voice: 412.481.5406 | fax: 412.431.1315
