Iso image integrity verification
Hi, We are going to use a OpenBSD system in a PCI-DSS compliant environment. Is there any way we can prove to our PCI-DSS assessor that the OpenBSD image we use for our installation can be checked so that it is the correct one (is not modified in a malicious way by a third party) ? A https link to some kind of ISO checksum or something similar (but using strong cryptography) I think would do it, but I could not find any (except a line in the FAQ stating If the men in black suits are out to get you, they're going to get you. which is not the case :) ) Thanks, Valentin Zagura
Re: Iso image integrity verification
The sha256 file located in the directory with the installxx.iso image has the sha256 checksum for all of the files in that directory. On Sep 11, 2013, at 5:49 AM, Valentin Zagura put...@gmail.com wrote: Hi, We are going to use a OpenBSD system in a PCI-DSS compliant environment. Is there any way we can prove to our PCI-DSS assessor that the OpenBSD image we use for our installation can be checked so that it is the correct one (is not modified in a malicious way by a third party) ? A https link to some kind of ISO checksum or something similar (but using strong cryptography) I think would do it, but I could not find any (except a line in the FAQ stating If the men in black suits are out to get you, they're going to get you. which is not the case :) ) Thanks, Valentin Zagura
Re: Iso image integrity verification
Yes, we know, but that file can also be easily compromised if it's not available for download with a secure protocol (HTTPS) On Wed, Sep 11, 2013 at 1:59 PM, Stan Gammons s_gamm...@charter.net wrote: The sha256 file located in the directory with the installxx.iso image has the sha256 checksum for all of the files in that directory. On Sep 11, 2013, at 5:49 AM, Valentin Zagura put...@gmail.com wrote: Hi, We are going to use a OpenBSD system in a PCI-DSS compliant environment. Is there any way we can prove to our PCI-DSS assessor that the OpenBSD image we use for our installation can be checked so that it is the correct one (is not modified in a malicious way by a third party) ? A https link to some kind of ISO checksum or something similar (but using strong cryptography) I think would do it, but I could not find any (except a line in the FAQ stating If the men in black suits are out to get you, they're going to get you. which is not the case :) ) Thanks, Valentin Zagura
Re: Iso image integrity verification
On Wed, Sep 11, 2013 at 03:17:20PM +0300, Valentin Zagura wrote: Yes, we know, but that file can also be easily compromised if it's not available for download with a secure protocol (HTTPS) So get the CD. You'll support the project as well. -Otto On Wed, Sep 11, 2013 at 1:59 PM, Stan Gammons s_gamm...@charter.net wrote: The sha256 file located in the directory with the installxx.iso image has the sha256 checksum for all of the files in that directory. On Sep 11, 2013, at 5:49 AM, Valentin Zagura put...@gmail.com wrote: Hi, We are going to use a OpenBSD system in a PCI-DSS compliant environment. Is there any way we can prove to our PCI-DSS assessor that the OpenBSD image we use for our installation can be checked so that it is the correct one (is not modified in a malicious way by a third party) ? A https link to some kind of ISO checksum or something similar (but using strong cryptography) I think would do it, but I could not find any (except a line in the FAQ stating If the men in black suits are out to get you, they're going to get you. which is not the case :) ) Thanks, Valentin Zagura
Re: Iso image integrity verification
+1 on this, to make sure that your OpenBSD Distribution is legit, get the CD, support the project! what more could you ask for ;) On Wed, Sep 11, 2013 at 4:58 AM, Peter N. M. Hansteen pe...@bsdly.netwrote: On Wed, Sep 11, 2013 at 01:49:14PM +0300, Valentin Zagura wrote: We are going to use a OpenBSD system in a PCI-DSS compliant environment. Is there any way we can prove to our PCI-DSS assessor that the OpenBSD image we use for our installation can be checked so that it is the correct one (is not modified in a malicious way by a third party) ? Probably not what you want to hear, but starting with http://www.openbsd.org/orders.html is usually an excellent idea in this context. Verifiably delivered from a trusted source. A https link to some kind of ISO checksum or something similar (but using strong cryptography) I think would do it, but I could not find any (except a line in the FAQ stating If the men in black suits are out to get you, they're going to get you. which is not the case :) ) It's possible some of the more prominent entries on http://www.openbsd.org/support.html could be persuaded to provide something like that (M:Tier comes to mind, but why are they not on that page?) in exchange for a reasonable fee. But again, for -RELEASE, the CD sets are a good starting point. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Disclaimer: http://goldmark.org/jeff/stupid-disclaimers/
Re: Iso image integrity verification
I love the stickers to enclose the box when getting a CD release, probably easy to forge but so cool :-) On Wed, Sep 11, 2013 at 9:00 AM, Beavis pfu...@gmail.com wrote: +1 on this, to make sure that your OpenBSD Distribution is legit, get the CD, support the project! what more could you ask for ;) On Wed, Sep 11, 2013 at 4:58 AM, Peter N. M. Hansteen pe...@bsdly.net wrote: On Wed, Sep 11, 2013 at 01:49:14PM +0300, Valentin Zagura wrote: We are going to use a OpenBSD system in a PCI-DSS compliant environment. Is there any way we can prove to our PCI-DSS assessor that the OpenBSD image we use for our installation can be checked so that it is the correct one (is not modified in a malicious way by a third party) ? Probably not what you want to hear, but starting with http://www.openbsd.org/orders.html is usually an excellent idea in this context. Verifiably delivered from a trusted source. A https link to some kind of ISO checksum or something similar (but using strong cryptography) I think would do it, but I could not find any (except a line in the FAQ stating If the men in black suits are out to get you, they're going to get you. which is not the case :) ) It's possible some of the more prominent entries on http://www.openbsd.org/support.html could be persuaded to provide something like that (M:Tier comes to mind, but why are they not on that page?) in exchange for a reasonable fee. But again, for -RELEASE, the CD sets are a good starting point. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Disclaimer: http://goldmark.org/jeff/stupid-disclaimers/ -- - () ascii ribbon campaign - against html e-mail /\
Re: Iso image integrity verification
Thanks for the suggestion, we will probably order the CD. But on the other hand, I hope that you realize that people in some countries (Iran, China, Egypt, Syria) would not have this possibility and they could be more affected by a compromise than we would be (they might probably pay with their lives) and I hope you guys are also thinking of them. Thanks, Valentin Zagura On Wed, Sep 11, 2013 at 1:58 PM, Peter N. M. Hansteen pe...@bsdly.netwrote: On Wed, Sep 11, 2013 at 01:49:14PM +0300, Valentin Zagura wrote: We are going to use a OpenBSD system in a PCI-DSS compliant environment. Is there any way we can prove to our PCI-DSS assessor that the OpenBSD image we use for our installation can be checked so that it is the correct one (is not modified in a malicious way by a third party) ? Probably not what you want to hear, but starting with http://www.openbsd.org/orders.html is usually an excellent idea in this context. Verifiably delivered from a trusted source. A https link to some kind of ISO checksum or something similar (but using strong cryptography) I think would do it, but I could not find any (except a line in the FAQ stating If the men in black suits are out to get you, they're going to get you. which is not the case :) ) It's possible some of the more prominent entries on http://www.openbsd.org/support.html could be persuaded to provide something like that (M:Tier comes to mind, but why are they not on that page?) in exchange for a reasonable fee. But again, for -RELEASE, the CD sets are a good starting point. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Iso image integrity verification
So you publish something on a HTTPS page, which means that when the browser says green padlock, it only says: this site was using a key signed by someone who in turn was signed by someone out of a few hundred CAs in a list which include companies in scary countries*. That will help a lot. *) Please exchange the list of scary countries to whatever scares you in your particular example. For Syria it could be the US, for US it could be Syria. Or some other combination of opposition. 2013/9/11 Valentin Zagura put...@gmail.com Thanks for the suggestion, we will probably order the CD. But on the other hand, I hope that you realize that people in some countries (Iran, China, Egypt, Syria) would not have this possibility and they could be more affected by a compromise than we would be (they might probably pay with their lives) and I hope you guys are also thinking of them. Thanks, Valentin Zagura On Wed, Sep 11, 2013 at 1:58 PM, Peter N. M. Hansteen pe...@bsdly.net wrote: On Wed, Sep 11, 2013 at 01:49:14PM +0300, Valentin Zagura wrote: We are going to use a OpenBSD system in a PCI-DSS compliant environment. Is there any way we can prove to our PCI-DSS assessor that the OpenBSD image we use for our installation can be checked so that it is the correct one (is not modified in a malicious way by a third party) ? Probably not what you want to hear, but starting with http://www.openbsd.org/orders.html is usually an excellent idea in this context. Verifiably delivered from a trusted source. A https link to some kind of ISO checksum or something similar (but using strong cryptography) I think would do it, but I could not find any (except a line in the FAQ stating If the men in black suits are out to get you, they're going to get you. which is not the case :) ) It's possible some of the more prominent entries on http://www.openbsd.org/support.html could be persuaded to provide something like that (M:Tier comes to mind, but why are they not on that page?) in exchange for a reasonable fee. But again, for -RELEASE, the CD sets are a good starting point. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. -- May the most significant bit of your life be positive.
Re: Iso image integrity verification
also means somebody paid a lot of money for that green bar On 09/11/2013 04:46 PM, Janne Johansson wrote: So you publish something on a HTTPS page, which means that when the browser says green padlock, it only says: this site was using a key signed by someone who in turn was signed by someone out of a few hundred CAs in a list which include companies in scary countries*. That will help a lot. *) Please exchange the list of scary countries to whatever scares you in your particular example. For Syria it could be the US, for US it could be Syria. Or some other combination of opposition. 2013/9/11 Valentin Zagura put...@gmail.com Thanks for the suggestion, we will probably order the CD. But on the other hand, I hope that you realize that people in some countries (Iran, China, Egypt, Syria) would not have this possibility and they could be more affected by a compromise than we would be (they might probably pay with their lives) and I hope you guys are also thinking of them. Thanks, Valentin Zagura On Wed, Sep 11, 2013 at 1:58 PM, Peter N. M. Hansteen pe...@bsdly.net wrote: On Wed, Sep 11, 2013 at 01:49:14PM +0300, Valentin Zagura wrote: We are going to use a OpenBSD system in a PCI-DSS compliant environment. Is there any way we can prove to our PCI-DSS assessor that the OpenBSD image we use for our installation can be checked so that it is the correct one (is not modified in a malicious way by a third party) ? Probably not what you want to hear, but starting with http://www.openbsd.org/orders.html is usually an excellent idea in this context. Verifiably delivered from a trusted source. A https link to some kind of ISO checksum or something similar (but using strong cryptography) I think would do it, but I could not find any (except a line in the FAQ stating If the men in black suits are out to get you, they're going to get you. which is not the case :) ) It's possible some of the more prominent entries on http://www.openbsd.org/support.html could be persuaded to provide something like that (M:Tier comes to mind, but why are they not on that page?) in exchange for a reasonable fee. But again, for -RELEASE, the CD sets are a good starting point. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. Mit freundlichen Grüßen Robert Garrett Senior System Engineer Technical Projects Solutions -- InterNetX GmbH Maximilianstr. 6 93047 Regensburg Germany Tel. +49 941 59559-480 Fax +49 941 59559-245 www.internetx.com www.facebook.com/InterNetX www.twitter.com/InterNetX Geschäftsführer/CEO: Thomas Mörz Amtsgericht Regensburg, HRB 7142
Re: Iso image integrity verification
That could also mean This is THE openbsd.org site if you're using eff ssl observatory. On Wed, Sep 11, 2013 at 5:46 PM, Janne Johansson icepic...@gmail.comwrote: So you publish something on a HTTPS page, which means that when the browser says green padlock, it only says: this site was using a key signed by someone who in turn was signed by someone out of a few hundred CAs in a list which include companies in scary countries*. That will help a lot. *) Please exchange the list of scary countries to whatever scares you in your particular example. For Syria it could be the US, for US it could be Syria. Or some other combination of opposition. 2013/9/11 Valentin Zagura put...@gmail.com Thanks for the suggestion, we will probably order the CD. But on the other hand, I hope that you realize that people in some countries (Iran, China, Egypt, Syria) would not have this possibility and they could be more affected by a compromise than we would be (they might probably pay with their lives) and I hope you guys are also thinking of them. Thanks, Valentin Zagura On Wed, Sep 11, 2013 at 1:58 PM, Peter N. M. Hansteen pe...@bsdly.net wrote: On Wed, Sep 11, 2013 at 01:49:14PM +0300, Valentin Zagura wrote: We are going to use a OpenBSD system in a PCI-DSS compliant environment. Is there any way we can prove to our PCI-DSS assessor that the OpenBSD image we use for our installation can be checked so that it is the correct one (is not modified in a malicious way by a third party) ? Probably not what you want to hear, but starting with http://www.openbsd.org/orders.html is usually an excellent idea in this context. Verifiably delivered from a trusted source. A https link to some kind of ISO checksum or something similar (but using strong cryptography) I think would do it, but I could not find any (except a line in the FAQ stating If the men in black suits are out to get you, they're going to get you. which is not the case :) ) It's possible some of the more prominent entries on http://www.openbsd.org/support.html could be persuaded to provide something like that (M:Tier comes to mind, but why are they not on that page?) in exchange for a reasonable fee. But again, for -RELEASE, the CD sets are a good starting point. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. -- May the most significant bit of your life be positive.
Re: Iso image integrity verification
On Wed, Sep 11, 2013 at 05:36:45PM +0300, Valentin Zagura wrote: Thanks for the suggestion, we will probably order the CD. But on the other hand, I hope that you realize that people in some countries (Iran, China, Egypt, Syria) would not have this possibility and they could be more affected by a compromise than we would be (they might probably pay with their lives) and I hope you guys are also thinking of them. Thanks, Valentin Zagura Do your homework. There are specifically companies that deal with OpenBSD in such countries, most specially the ones who can't deal with the US because of embargoes...
Re: Iso image integrity verification
And from that we can deduce what? $evil_country can't spend $10k to be able to intercept and silently MITM all https? 2013/9/11 InterNetX - Robert Garrett robert.garr...@internetx.com also means somebody paid a lot of money for that green bar On 09/11/2013 04:46 PM, Janne Johansson wrote: So you publish something on a HTTPS page, which means that when the browser says green padlock, it only says: this site was using a key signed by someone who in turn was signed by someone out of a few hundred CAs in a list which include companies in scary countries*. That will help a lot. *) Please exchange the list of scary countries to whatever scares you in your particular example. For Syria it could be the US, for US it could be Syria. Or some other combination of opposition. 2013/9/11 Valentin Zagura put...@gmail.com Thanks for the suggestion, we will probably order the CD. But on the other hand, I hope that you realize that people in some countries (Iran, China, Egypt, Syria) would not have this possibility and they could be more affected by a compromise than we would be (they might probably pay with their lives) and I hope you guys are also thinking of them. Thanks, Valentin Zagura On Wed, Sep 11, 2013 at 1:58 PM, Peter N. M. Hansteen pe...@bsdly.net wrote: On Wed, Sep 11, 2013 at 01:49:14PM +0300, Valentin Zagura wrote: We are going to use a OpenBSD system in a PCI-DSS compliant environment. Is there any way we can prove to our PCI-DSS assessor that the OpenBSD image we use for our installation can be checked so that it is the correct one (is not modified in a malicious way by a third party) ? Probably not what you want to hear, but starting with http://www.openbsd.org/orders.**htmlhttp://www.openbsd.org/orders.html is usually an excellent idea in this context. Verifiably delivered from a trusted source. A https link to some kind of ISO checksum or something similar (but using strong cryptography) I think would do it, but I could not find any (except a line in the FAQ stating If the men in black suits are out to get you, they're going to get you. which is not the case :) ) It's possible some of the more prominent entries on http://www.openbsd.org/**support.htmlhttp://www.openbsd.org/support.html could be persuaded to provide something like that (M:Tier comes to mind, but why are they not on that page?) in exchange for a reasonable fee. But again, for -RELEASE, the CD sets are a good starting point. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. Mit freundlichen Grüßen Robert Garrett Senior System Engineer Technical Projects Solutions -- InterNetX GmbH Maximilianstr. 6 93047 Regensburg Germany Tel. +49 941 59559-480 Fax +49 941 59559-245 www.internetx.com www.facebook.com/InterNetX www.twitter.com/InterNetX Geschäftsführer/CEO: Thomas Mörz Amtsgericht Regensburg, HRB 7142 -- May the most significant bit of your life be positive.
Re: Iso image integrity verification
On 2013/09/11 16:46, Janne Johansson wrote: So you publish something on a HTTPS page, which means that when the browser says green padlock, it only says: this site was using a key signed by someone who in turn was signed by someone out of a few hundred CAs in a list which include companies in scary countries*. That will help a lot. Also it says nothing about the contents of the *files* on that site...
Re: Iso image integrity verification
I think you are missing two very important points that are addressed in the official documentation and have been pointed out to you by other respondents: 1. what you are asking for provides NO real added security, and perhaps just the opposite through FALSE SENSE of security, and 2. the fact that other projects choose to offer such ineffective solutions does not mean that it is the right thing to do -- and OpenBSD is notorious for doing The Right Thing(TM) however unpopular that may be. P.S. (to regulars and moderators) Does this discussion really belong on tech or is this more in line with misc@ noise? On 11 Sep 2013 at 20:53, Valentin Zagura wrote: I don't think I'm more paranoid than the average considering that Debian has a way to do this (http://www.debian.org/CD/verify), fedora has a way to do this (https://fedoraproject.org/verify), even Freebsd has a way to do this ( https://www.freebsd.org/releases/9.1R/announce.html). The thought of being more paranoid than an OpenBSD guy is not very comfortable :) On Wed, Sep 11, 2013 at 8:13 PM, Daniel Bolgheroni dan...@bolgh.eng.brwrote: On Wed, Sep 11, 2013 at 03:17:20PM +0300, Valentin Zagura wrote: Yes, we know, but that file can also be easily compromised if it's not available for download with a secure protocol (HTTPS) If you're paranoid, build your own hardware from the ground up, including designing your own CPU and complementary circuits, download all the sources, audit them all, compile and then run. You can't be fooled by wrong measurements of security.
Re: Iso image integrity verification
I don't think I'm more paranoid than the average considering that Debian has a way to do this (http://www.debian.org/CD/verify), fedora has a way to do this (https://fedoraproject.org/verify), even Freebsd has a way to do this ( https://www.freebsd.org/releases/9.1R/announce.html). The thought of being more paranoid than an OpenBSD guy is not very comfortable :) On Wed, Sep 11, 2013 at 8:13 PM, Daniel Bolgheroni dan...@bolgh.eng.brwrote: On Wed, Sep 11, 2013 at 03:17:20PM +0300, Valentin Zagura wrote: Yes, we know, but that file can also be easily compromised if it's not available for download with a secure protocol (HTTPS) If you're paranoid, build your own hardware from the ground up, including designing your own CPU and complementary circuits, download all the sources, audit them all, compile and then run. You can't be fooled by wrong measurements of security.
Re: Iso image integrity verification
There's literally the same thing on the mirror? http://ftp.openbsd.org/pub/OpenBSD/snapshots/amd64/SHA256 On Wed, Sep 11, 2013 at 1:53 PM, Valentin Zagura put...@gmail.com wrote: I don't think I'm more paranoid than the average considering that Debian has a way to do this (http://www.debian.org/CD/verify), fedora has a way to do this (https://fedoraproject.org/verify), even Freebsd has a way to do this ( https://www.freebsd.org/releases/9.1R/announce.html). The thought of being more paranoid than an OpenBSD guy is not very comfortable :) On Wed, Sep 11, 2013 at 8:13 PM, Daniel Bolgheroni dan...@bolgh.eng.brwrote: On Wed, Sep 11, 2013 at 03:17:20PM +0300, Valentin Zagura wrote: Yes, we know, but that file can also be easily compromised if it's not available for download with a secure protocol (HTTPS) If you're paranoid, build your own hardware from the ground up, including designing your own CPU and complementary circuits, download all the sources, audit them all, compile and then run. You can't be fooled by wrong measurements of security.
Re: Iso image integrity verification
On Wed, Sep 11, 2013 at 01:57:22PM -0400, Brandon Mercer wrote: There's literally the same thing on the mirror? http://ftp.openbsd.org/pub/OpenBSD/snapshots/amd64/SHA256 This discussion is probably more suited for misc@, but as Brandon wrote, SHA256 checksums are on all the mirrors. If you don't trust your local ftp.openbsdmirror.ccTLD, it might be worth fetching the sets and then grabbing the SHA256 file directly from ftp.openbsd.org. -Bryan.
Re: Iso image integrity verification
On Wed, Sep 11, 2013 at 03:17:20PM +0300, Valentin Zagura wrote: Yes, we know, but that file can also be easily compromised if it's not available for download with a secure protocol (HTTPS) If you're paranoid, build your own hardware from the ground up, including designing your own CPU and complementary circuits, download all the sources, audit them all, compile and then run. You can't be fooled by wrong measurements of security.
Re: Iso image integrity verification
maintaining a mirror and a cvs sync tree is quite good too. morevover you cloud have some https on your mirror On Wed, Sep 11, 2013 at 1:53 PM, Valentin Zagura put...@gmail.com wrote: I don't think I'm more paranoid than the average considering that Debian has a way to do this (http://www.debian.org/CD/verify), fedora has a way to do this (https://fedoraproject.org/verify), even Freebsd has a way to do this ( https://www.freebsd.org/releases/9.1R/announce.html). The thought of being more paranoid than an OpenBSD guy is not very comfortable :) On Wed, Sep 11, 2013 at 8:13 PM, Daniel Bolgheroni dan...@bolgh.eng.br wrote: On Wed, Sep 11, 2013 at 03:17:20PM +0300, Valentin Zagura wrote: Yes, we know, but that file can also be easily compromised if it's not available for download with a secure protocol (HTTPS) If you're paranoid, build your own hardware from the ground up, including designing your own CPU and complementary circuits, download all the sources, audit them all, compile and then run. You can't be fooled by wrong measurements of security. -- - () ascii ribbon campaign - against html e-mail /\
Re: Iso image integrity verification
If I were a dissident in one of those countries, I would not trust a third party with my life (but maybe I'm too paranoid). AFAIK OpenBSD is Canada, not US, but again, I might be wrong.
Re: Iso image integrity verification
On Wed, Sep 11, 2013 at 08:53:50PM +0300, Valentin Zagura wrote: I don't think I'm more paranoid than the average considering that Debian has a way to do this (http://www.debian.org/CD/verify), fedora has a way to do this (https://fedoraproject.org/verify), even Freebsd has a way to do this ( https://www.freebsd.org/releases/9.1R/announce.html). So you're saying that less paranoid projects are doing it, so why doesn't OpenBSD join the crowd and provide some fuzzy feel good but pointless security theatre? :-) The thought of being more paranoid than an OpenBSD guy is not very comfortable :) Don't worry. You're apparently not paranoid enough yet. The true practical paranoid does not waste time on such mummery. Ken On Wed, Sep 11, 2013 at 8:13 PM, Daniel Bolgheroni dan...@bolgh.eng.brwrote: On Wed, Sep 11, 2013 at 03:17:20PM +0300, Valentin Zagura wrote: Yes, we know, but that file can also be easily compromised if it's not available for download with a secure protocol (HTTPS) If you're paranoid, build your own hardware from the ground up, including designing your own CPU and complementary circuits, download all the sources, audit them all, compile and then run. You can't be fooled by wrong measurements of security.
Re: Iso image integrity verification
On Wed, Sep 11, 2013 at 08:42:46PM +0300, Valentin Zagura wrote: The idea was to display a checksum of the files on such a https page. Like for example https://www.freebsd.org/releases/9.1R/announce.html at the bottom of the page. On Wed, Sep 11, 2013 at 7:18 PM, Stuart Henderson st...@openbsd.org wrote: On 2013/09/11 16:46, Janne Johansson wrote: So you publish something on a HTTPS page, which means that when the browser says green padlock, it only says: this site was using a key signed by someone who in turn was signed by someone out of a few hundred CAs in a list which include companies in scary countries*. That will help a lot. Add to that most of the top-level CAs are U.S. based and just as likely to bend over as Surprizon, USFest, Microslop, etc. the certificates they issue are probably not worth a damn much less those issued by intermediate CAs. Also it says nothing about the contents of the *files* on that site... You can PGP clearsign webpages. It's kind of cool but how many people are actually going to verify them? Maybe if there was a Firefox plugin grin
Re: osfp pfctl and states
If I want this on FreeBSD i am alone, but here...
So this code check the fingerprint, and does not bother to save it, because
it is never used , and that s good :-)
I read the code a bit:
pf.c : around line 3232
- - - - - -
case IPPROTO_TCP:
PF_TEST_ATTRIB(((r-flagset th-th_flags) !=
r-flags),
TAILQ_NEXT(r, entries));
PF_TEST_ATTRIB((r-os_fingerprint != PF_OSFP_ANY
!pf_osfp_match(pf_osfp_fingerprint(pd),
r-os_fingerprint)),
TAILQ_NEXT(r, entries));
- - - - - -
1/
At his point struct pf_state **sm is available.
Lets assume pf_state got a struct pf_osfp_enlist l_osfp
To get back the info from userland, doing
TAILQ_NEXT(r, entries));
//pf_osfp_fingerprint return the list of matching os for the fingerprint
//afaik this list is save during initilized so we saved the pointer .
struct pf_osfp_enlist * _l_osfp = pf_osfp_fingerprint(pd);
(*sm)-l_osfp = _l_osfp;
PF_TEST_ATTRIB((r-os_fingerprint != PF_OSFP_ANY
!pf_osfp_match(p_osfp,
r-os_fingerprint)),http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf_osfp.c#rev1.25
Would a diff like this hurts ??
Nevertheless:::
2/ Few problems remains:
a/ copying this to the pfsync_struct,
b/ ioctl wont be able to send the data or must copy the all list (next
point solve this)
c/ the data i want is more the one hidden
in pf_osfp_fingerprint_hdr around line 112
struct pf_os_fingerprint fp;
To get this back i should pass sm as argument to pf_osfp_fingerprint and
pf_osfp_fingerprint_hdr
and do
sm-fp = fp;
inside
Would a diff like this hurts ??
Digression:
I found the osfp code a bit stange as the fp is not get trough a function
and then pass to the matcher.
pf_osfp_fingerprint_hdr calcute the value and look for the entry
then pass the list of compatible os, a function that compute the fp to
get somethink like this:
fp = pf_osfp_get_fingerprint(pd);
if (fp) {
struct pf_osfp_enlist * oses = pf_osfp_get_oses(fp); //inside
pf_osfp_match
pf_osfp_match(oses ,
r-os_fingerprint)),http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf_osfp.c#rev1.25
}
Btw, the goal is to know how many different fingerprint come from from one
source without doing log or traffic analysis.
On Fri, Sep 6, 2013 at 5:27 AM, Henning Brauer lists-openbsdt...@bsws.dewrote:
* sven falempin sven.falem...@gmail.com [2013-09-05 18:14]:
Reading pfctl manual and net/pfvar.h i didnt find the ospf information
inside a states entry .
So i assume it is not possible to recover the fingerprint of a state
trough
the ioctl.
otoh this is the case.
- creatorId is something i hould look into.
no, creatorID is for pfsync setups to know which node created the
state.
--
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services GmbH, http://bsws.de, Full-Service ISP
Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully
Managed
Henning Brauer Consulting, http://henningbrauer.com/
--
-
() ascii ribbon campaign - against html e-mail
/\
Re: Iso image integrity verification
I was saying that other projects do it in a way they feel comfortable with and maybe you will find a way to do it that you are comfortable with. Using https was one simple idea. I understand that you don't think that this adds any value but maybe there are other ways like signing with PGP, maybe using SSH somehow or having Theo de Raadt saying the SHA checksums on a video on youtube at each release :) or some other simple and effective way that you are comfortable with. I just wanted to point out that one can not easely show his security assessor that it has the right images using some industry standard ways, or someone living in a country that has an oppressive government and would download the image through tor could have some problems if the exit node is malicious. If you feel that any kind of verification is futile, it's ok, that would not stop us from buying the CDs. On Wed, Sep 11, 2013 at 10:32 PM, Kenneth R Westerback kwesterb...@rogers.com wrote: On Wed, Sep 11, 2013 at 08:53:50PM +0300, Valentin Zagura wrote: I don't think I'm more paranoid than the average considering that Debian has a way to do this (http://www.debian.org/CD/verify), fedora has a way to do this (https://fedoraproject.org/verify), even Freebsd has a way to do this ( https://www.freebsd.org/releases/9.1R/announce.html). So you're saying that less paranoid projects are doing it, so why doesn't OpenBSD join the crowd and provide some fuzzy feel good but pointless security theatre? :-) The thought of being more paranoid than an OpenBSD guy is not very comfortable :) Don't worry. You're apparently not paranoid enough yet. The true practical paranoid does not waste time on such mummery. Ken On Wed, Sep 11, 2013 at 8:13 PM, Daniel Bolgheroni dan...@bolgh.eng.br wrote: On Wed, Sep 11, 2013 at 03:17:20PM +0300, Valentin Zagura wrote: Yes, we know, but that file can also be easily compromised if it's not available for download with a secure protocol (HTTPS) If you're paranoid, build your own hardware from the ground up, including designing your own CPU and complementary circuits, download all the sources, audit them all, compile and then run. You can't be fooled by wrong measurements of security.
INADDR_ANY in pflow(4)
Since no one presented a case why sending from INADDR_ANY is a good
thing[tm], make it clear that it won't work.
The ifconfig(8) diff generates this output:
$ sudo ifconfig pflow0 up
$ ifconfig pflow0
pflow0: flags=1UP mtu 1492
priority: 0
pflow: sender: INVALID receiver: INVALID:INVALID version: 5
groups: pflow
Comments/OK?
(While there make the SIOCSIFFLAGS and SIOCSETPFLOW cases symetric by
only sending templates if the interface is running, this doesn't
change behaviour because the pflow_sendout_{v9,ipfix}_tmpl functions
are checking for running themself.)
diff --git sbin/ifconfig/ifconfig.8 sbin/ifconfig/ifconfig.8
index 9e43660..fa65426 100644
--- sbin/ifconfig/ifconfig.8
+++ sbin/ifconfig/ifconfig.8
@@ -1224,11 +1224,12 @@ Pflow data will be sent to this address/port.
Unset the receiver address and stop sending pflow data.
.It Cm flowsrc Ar addr
Set the source IP address for pflow packets.
+Must be defined to export pflow data.
.Ar addr
is the IP address used as sender of the UDP packets and may be used to
identify the source of the data on the pflow collector.
.It Fl flowsrc
-Unset the source address.
+Unset the source address and stop sending pflow data.
.It Cm pflowproto Ar n
Set the protocol version.
The default is version 5.
diff --git sbin/ifconfig/ifconfig.c sbin/ifconfig/ifconfig.c
index da03a75..1351319 100644
--- sbin/ifconfig/ifconfig.c
+++ sbin/ifconfig/ifconfig.c
@@ -3808,9 +3808,14 @@ pflow_status(void)
if (ioctl(s, SIOCGETPFLOW, (caddr_t)ifr) == -1)
return;
- printf(\tpflow: sender: %s , inet_ntoa(preq.sender_ip));
- printf(receiver: %s:%u , inet_ntoa(preq.receiver_ip),
- ntohs(preq.receiver_port));
+ printf(\tpflow: sender: %s , preq.sender_ip.s_addr != INADDR_ANY ?
+ inet_ntoa(preq.sender_ip) : INVALID);
+ printf(receiver: %s:, preq.receiver_ip.s_addr != INADDR_ANY ?
+ inet_ntoa(preq.receiver_ip) : INVALID);
+ if (preq.receiver_port == 0)
+ printf(%s , INVALID);
+ else
+ printf(%u , ntohs(preq.receiver_port));
printf(version: %d\n, preq.version);
}
diff --git share/man/man4/pflow.4 share/man/man4/pflow.4
index 8b0e74b..6500888 100644
--- share/man/man4/pflow.4
+++ share/man/man4/pflow.4
@@ -42,8 +42,8 @@ Multiple
interfaces can be created at runtime using the
.Ic ifconfig pflow Ns Ar N Ic create
command.
-Each interface must be configured with a flow receiver IP address and
-port number.
+Each interface must be configured with flow sender IP address and a flow
+receiver IP address and port number.
.Pp
Only states created by a rule marked with the
.Ar pflow
@@ -91,6 +91,8 @@ collector.
.Cm flowdst
defines the collector IP address and the port.
The
+.Cm flowsrc
+IP address and
.Cm flowdst
IP address and port must be defined to enable the export of flows.
.Pp
diff --git sys/net/if_pflow.c sys/net/if_pflow.c
index ba51cb1..0f026f9 100644
--- sys/net/if_pflow.c
+++ sys/net/if_pflow.c
@@ -151,7 +151,7 @@ pflow_clone_create(struct if_clone *ifc, int unit)
(sizeof(struct in_multi *) * IP_MIN_MEMBERSHIPS), M_IPMOPTS,
M_WAITOK|M_ZERO);
pflowif-sc_imo.imo_max_memberships = IP_MIN_MEMBERSHIPS;
- pflowif-sc_receiver_ip.s_addr = 0;
+ pflowif-sc_receiver_ip.s_addr = INADDR_ANY;
pflowif-sc_receiver_port = 0;
pflowif-sc_sender_ip.s_addr = INADDR_ANY;
pflowif-sc_sender_port = pflow_get_dynport();
@@ -428,8 +428,10 @@ pflowioctl(struct ifnet *ifp, u_long cmd, caddr_t data)
case SIOCSIFDSTADDR:
case SIOCSIFFLAGS:
if ((ifp-if_flags IFF_UP)
- sc-sc_receiver_ip.s_addr != 0
- sc-sc_receiver_port != 0) {
+ sc-sc_receiver_ip.s_addr != INADDR_ANY
+ sc-sc_receiver_port != 0
+ sc-sc_sender_ip.s_addr != INADDR_ANY
+ sc-sc_sender_port != 0) {
ifp-if_flags |= IFF_RUNNING;
sc-sc_gcounter=pflowstats.pflow_flows;
/* send templates on startup */
@@ -491,7 +493,7 @@ pflowioctl(struct ifnet *ifp, u_long cmd, caddr_t data)
pflow_flush(sc);
if (pflowr.addrmask PFLOW_MASK_DSTIP)
- sc-sc_receiver_ip = pflowr.receiver_ip;
+ sc-sc_receiver_ip.s_addr = pflowr.receiver_ip.s_addr;
if (pflowr.addrmask PFLOW_MASK_DSTPRT)
sc-sc_receiver_port = pflowr.receiver_port;
if (pflowr.addrmask PFLOW_MASK_SRCIP)
@@ -503,18 +505,24 @@ pflowioctl(struct ifnet *ifp, u_long cmd, caddr_t data)
pflow_setmtu(sc, ETHERMTU);
pflow_init_timeouts(sc);
- if (sc-sc_version == PFLOW_PROTO_9)
- pflow_sendout_v9_tmpl(sc);
- else if (sc-sc_version == PFLOW_PROTO_10)
-
Re: Iso image integrity verification
On 11 September 2013 20:42, Valentin Zagura put...@gmail.com wrote: The idea was to display a checksum of the files on such a https page. Like for example https://www.freebsd.org/releases/9.1R/announce.html at the bottom of the page. Not sure whether this is already proposed but here's my two cents: why not to check SHA256 sums from the various mirrors and perform the comparison? -- Cheers, Ville Valkonen
Re: Iso image integrity verification
On 2013/09/12 00:55, Ville Valkonen wrote: Not sure whether this is already proposed but here's my two cents: why not to check SHA256 sums from the various mirrors and perform the comparison? -- Cheers, Ville Valkonen How does this help prove that the files haven't been tampered with? If someone malicious is sitting close to you in your network path, they can just as easily pretend to be all the mirrors as they can pretend to be just one of them.
Re: defer routing table updates on link state changes
On Tue, Aug 27, 2013 at 01:39:14PM +0200, Martin Pieuchot wrote:
On 26/08/13(Mon) 13:36, Mike Belopuhov wrote:
hi,
in order to make our life a bit easier and prevent rogue
accesses to the routing table from the hardware interrupt
context violating all kinds of spl assumptions we would
like if_link_state_change that is called by network device
drivers in their interrupt service routines to defer its
work to the process context or thereabouts.
i did some testing here, but wouldn't mind if someone
tries this diff in gre/vlan/ospf/anything-weird setups.
making sure that hot-plugging/unplugging usb interfaces
doesn't produce any undesirable effects would be superb
as well.
I just tested vlan and usb interfaces, it works just fine.
please note that a token (an interface index) is passed
to the workq in order to make sure that if the interface
would be gone by the time syswq goes around to run the
task it would just fall through.
I think that's the right approach but the current code generating
interfaces indexes is too clever from my point of view, it tries
to reuse the last index if possible. This could lead to some
funny races if we detach and reattach an interface before the
task get scheduled.
So I'm ok with your diff if we avoid to reuse the last index too
soon. Diff below does that.
We should not do that since this was done for tun(4) switching between
modes without getting new ifindexes. It also reduces the holes in the
ifindex array on system that dynamically allocate interfaces for e.g.
VPNs.
Index: net/if.c
===
RCS file: /home/ncvs/src/sys/net/if.c,v
retrieving revision 1.262
diff -u -p -r1.262 if.c
--- net/if.c 20 Aug 2013 09:14:22 - 1.262
+++ net/if.c 27 Aug 2013 10:22:44 -
@@ -204,31 +204,37 @@ if_attachsetup(struct ifnet *ifp)
{
int wrapped = 0;
- if (ifindex2ifnet == 0)
+ /*
+ * Always increment the index to avoid races.
+ */
+ if_index++;
+
+ /*
+ * If we hit USHRT_MAX, we skip back to 1 since there are a
+ * number of places where the value of ifp-if_index or
+ * if_index itself is compared to or stored in an unsigned
+ * short. By jumping back, we won't botch those assignments
+ * or comparisons.
+ */
+ if (if_index == USHRT_MAX) {
if_index = 1;
- else {
- while (if_index if_indexlim
- ifindex2ifnet[if_index] != NULL) {
- if_index++;
+ wrapped++;
+ }
+
+ while (if_index if_indexlim ifindex2ifnet[if_index] != NULL) {
+ if_index++;
+
+ if (if_index == USHRT_MAX) {
/*
- * If we hit USHRT_MAX, we skip back to 1 since
- * there are a number of places where the value
- * of ifp-if_index or if_index itself is compared
- * to or stored in an unsigned short. By
- * jumping back, we won't botch those assignments
- * or comparisons.
+ * If we have to jump back to 1 twice without
+ * finding an empty slot then there are too many
+ * interfaces.
*/
- if (if_index == USHRT_MAX) {
- if_index = 1;
- /*
- * However, if we have to jump back to 1
- * *twice* without finding an empty
- * slot in ifindex2ifnet[], then there
- * there are too many (65535) interfaces.
- */
- if (wrapped++)
- panic(too many interfaces);
- }
+ if (wrapped)
+ panic(too many interfaces);
+
+ if_index = 1;
+ wrapped++;
}
}
ifp-if_index = if_index;
--
:wq Claudio
Re: Split rtinit()
On Thu, Aug 29, 2013 at 11:20:56AM +0200, Martin Pieuchot wrote: On 27/08/13(Tue) 10:44, Kenneth R Westerback wrote: On Tue, Aug 27, 2013 at 03:38:49PM +0200, Martin Pieuchot wrote: So I started to play with the routine table and I'm slowly trying to unify the various code paths to add and delete route entries. The diff below is a first step, it splits rtinit() into rt_add() and rt_delete() there should be no functional change. ok? That makes s much more sense. :-). mikeb@ pointed out that the names I picked were maybe too generic. This kept me thinking and I'd like to try to separate the logic of adding a route to network vs route to host first. Why? There is no difference between a host route and a network route. The fact that the host route has no netmask should not result into a different set of functions. In other words, forget this diff for the moment (: -- :wq Claudio
